As far as I know, if a extension author wants to support translations for messages, their only option is to embed %MAKETEXT in the text of their messages / their templates. It's not clear to me what processes exist for them to get their strings added to the set of strings that get translated, or, if they are able to source their own translations, how they go about adding those strings to TWiki for MAKETEXT to pick up.

So, my proposal is in two parts:

Part one: add maketext to the Func API:

=pod

translate($string, ...) -> $translated_string

Looks in the lexicon for the currently-selected user interface language, and if a translation of $string exists, returns it with all the parameter values filled in. ... is an arbitrary length list of parameter values that will be used to fill in [_1], [_2] etc. placeholders in the string. Parameter values are not translated. English is used if no translation exists.

For example,

   my $mess = TWiki::Func::translate("Smoke me a [_1], I'll be back for [_2]", 'kipper', 'breakfast');

$mess will be returned as a translated string e.g.

• English: Smoke me a kipper, I'll be back for breakfast
• French: Fumee-moi un kipper, je retour pour breakfast
• German: Rauch mir mal ein kipper, ich kom zurück zum breakfast
• Gaelic: Smoke me a kipper, I'll be back for breakfast

(Gaelic has no translation of the string)

Since: 1.013

=cut

I am happy to commit to providing this interface for 4.2.

Part two: provide a mechanism for extension authors to get strings into the lexicon

The second part of the proposal is to document and develop a mechanism by which plugins authors can add strings to the general TWiki lexicon. This might involve a submission process for getting strings accepted into the central lexicon, or it might be a method by which plugins authors can provide their own lexicons for inclusion in the TWiki translation mechanisms.

I cannot commit to doing this.

-- Contributors: CrawfordCurrie - 25 Apr 2007

Discussion

I changed the CommittedDeveloper field (moved the note down in OutstandingIssues) so the search results do not get screwed up. no worries.

-- KennethLavrsen - 25 Apr 2007

What about (conditionally) "compile" the pot in bin/configure runtime? If there is a change in the plugins section, the pot file will be recompiled. I am not quite sure, but I think a simple copying into one file (for each language) will do.

-- OliverKrueger - 25 Apr 2007

Crawdord, why do you use so many h1 headers?

Yes, there should be a mechanism for add-ons as well. Perhaps the locale folder can have a folder for each add-on, and files in these folders can be picked up either by maketext (possible?) or by a combine script.

-- ArthurClemens - 25 Apr 2007

An experiment with performance measure is needed to really decide what to do. IIRC, TWiki initialization time goes up as the number of pot files loaded increases.

-- RafaelAlvarez - 25 Apr 2007

Would it help if we use mo files (compiled po)? Or does the TWiki caching do the same?

-- ArthurClemens - 26 Apr 2007

What TWiki Caching are you talking about Arthur? I do not recall that TWiki caches any of the info in .po files. The cache I know is the languages.cache file which only contains the short list of languages. If Maketext has to run through extra .po files for each plugin in misc subdirectories it will for sure mean an unacceptable performance hit. Already today the language feature is so costly in performance that I would not dream of enabling it.

-- KennethLavrsen - 26 Apr 2007

Ok so far for plugins. But how about TWikiApplications that add all sorts of new strings. Having one monolithic lexicon doesn't seem to fit.

-- MichaelDaum - 01 May 2007

I always thought we had created a language cache to address performance. Now we really need to look into reading mo files! See Gettext for info.

-- ArthurClemens - 02 May 2007

The cache that was implemented, as KennethLavrsen pointed out, is actually a mechanism to load only those languages that are enabled in configure instead of all language.

-- RafaelAlvarez - 04 May 2007

I see the above as exchange of ideas to further develop the translation support beyond the step 1 that Crawford has committed. If my interpretation is wrong then please pull the break today by adding your name in the ConcernRaisedBy field.

Otherwise it seems this one is accepted by 14 day rule tomorrow the 09 May 2007 and I personally recommend acceptance of the part 1 as it is pretty no-brainer.

-- KennethLavrsen - 08 May 2007

Part 1 accepted by 14 day rule.

The part 2 if ever committed should probably get its own proposal topic then.

-- KennethLavrsen - 09 May 2007

Here's a proposal for part 2. From my reading of lib/TWiki/I18N* then one simple approach would be to generate .pot files prefixed by the extension name e.g. SubscribePlugin_de.po.

From a plugin author perspective here's what they'd have to do:

1. Use %MAKETEXT and TWiki::Func::translate to identify all strings for translation. These would have to indicate the lexicon they come from e.g. %MAKETEXT{"Subscribe" lexicon="SubscribePlugin"}%
2. Use perl build.pl lexicon to build a lexicon for the extension (using the existing extraction code). This would generate locale/SubscribePlugin.pot
3. Use perl build.pl upload to upload the .pot file with all the other release files to twiki.org.
4. Spanish translator would create SubscribePlugin_es.po and upload it to TWiki.org

Now, the clever bit. When the plugin is installed, the installer script automatically goes back to twiki.org and downloads all the .po files it can find that are attached to the extension topic e.g it would look for es.po attached to SubscribePlugin. Obviously this step could also be done manually.

The advantages of this approach are:

1. Using TWiki.org to store the .po files means that anyone can come along and provide a translation for an extension as and when they feel motivated to do so.
2. Very few code changes are required.
3. Highly compatible with the current approach.

The disadvantages are:

1. No easy way to "queue" extensions for translation alongside the main TWiki.pot
2. No easy way to flag a translation as being out of date versus the .pot file

This would require changes to:

1. BuildContrib to support the lexicon target (which would be automatically included in the release and upload targets).
2. TWiki/I18N* to support use of lexicons other than the default TWiki lexicon

-- CrawfordCurrie - 03 Jun 2007

Please open a new proposal.

And no matter what - this is for GeorgetownRelease.

Was this proposal fully implemented?

-- KennethLavrsen - 03 Jun 2007

If .po files are attached to topics on twiki.org, I suppose they are not tracked in svn.

-- ArthurClemens - 03 Jun 2007