Hi everyone,
Currently translation of messages outputted to the wiki's is done in source. This is quite tedious to maintain. A good step would be to move translations to http://www.translatewiki.org so it is much easier to get things translated. But how? We have several options.
1. Gettext: http://en.wikipedia.org/wiki/GNU_gettext Supported by translatewiki, build in support in python (http://docs.python.org/library/gettext.html), but it doesn't seem to be really targeted on working on multiple languages the same time like we do in for example interwiki.py.
2. Big python dictionary: Easy to implement in pywikipedia but isn't really a standard so translatewiki needs to be modified. You can see a test in r8684
3. Properties files: http://en.wikipedia.org/wiki/.properties These files are used in Java programs to store translations. Supported at translatewiki. We could probably parse these with something like http://docs.python.org/library/configparser.html . Downside is that these files are not utf-8 encoded.
4. YAML : http://en.wikipedia.org/wiki/YAML . Supported by translatewiki, need a lib to use it in pywikipedia.
So what do you guys think? What should we do? Anyone willing to help implement this?
We've talked about this several times. I hope we manage to implement something this time :-)
Maarten
Hi Maarten,
On 23 October 2010 21:32, Maarten Dammers maarten@mdammers.nl wrote:
I have very bad experiences with gettext in python. I forgot what the issues were exactly, but I know it was annoying enough not to use it. I think it had something to do with actually switching languages, but I'm not 100% sure.
- Big python dictionary: Easy to implement in pywikipedia but isn't
really a standard so translatewiki needs to be modified. You can see a test in r8684
OK as far as I am concerned, but if TW does not support it, probably not the best option.
3. Properties files: http://en.wikipedia.org/wiki/.properties
- YAML : http://en.wikipedia.org/wiki/YAML .
These two are equal as far as I am concerned. I have more experience with YAML than with properties-based stuff, but I think for translations the only difference is the usage of : (YAML) instead of = (properties).
The big advantage of getting TW to export into the currently used format is obvious: it requires less changes at our end. However, in the long run, it would make sense to split off translations from the scripts and import them. The format we use at that point is pretty much irrelevant, as there will be some intermediate layer to read the translations.
Best regards, Merlijn
From: Merlijn van Deen Sent: Friday, October 29, 2010 11:54 AM
3. Properties files: http://en.wikipedia.org/wiki/.properties http://en.wikipedia.org/wiki/.properties 4. YAML : http://en.wikipedia.org/wiki/YAML .
These two are equal as far as I am concerned. I have more experience with YAML than with properties-based stuff, but I think for translations the only difference is the usage of : (YAML) instead of = (properties).
The big advantage of getting TW to export into the currently used format is obvious: it requires less changes at our end. However, in the long run, it would make sense to split off translations from the scripts and import them. The format we use at that point is pretty much irrelevant, as there will be some intermediate layer to read the translations.
Hi Merlijn. Thanks for your take.
On file formats and possible restrictions: two restriction for .properties that are not present in YAML:
· key=message *must* be on one line. In a YAML file this can span over multiple lines, as long as each preceeding line is closed with \
· no hierarchy can be used to make the messages file better structured and readable (f.e. have a hierarchy per script). YAML files *can* also be flat.
On current i18n structure of pwb and twn: Twn supporting the current structure is not going to happen. I’m only interested in supporting L10n for pwb at twn if pwb uses centralized file(s) with translations.
Siebrand