Official switch of translations to gettext

[yann]

The official switch to gettext is happening, with the imminent merge of the gettext branch into cvs trunk (really soon after 0.8.2 will be released). This means that the translations in the old data/translations/*.cfg file will need to be imported into po/*.po (or users of 0.8.3 will likely don't see your translation).

To avoid getting in the way of current translation work, I won't run the migration script myself on all langauges. The script will have to be run on a langauge once the coordinator for this language gives the green light, to avoid problems with not-yet-committed translation updates.

Please find details at http://wesnoth.slack.it/?GetText

[sanna]

Glad to see that the work has progressed to this point. While it will be quite a chore to 'unfuzz' the translations, in the long run this feature will greatly facilitate for translators.

Note that hungarian, polish, and swedish catalogs do not build because of too many missing newlines in their translations. I'll let the respective teams take care of this.

Since I've submitted the last swedish translation, I guess the 'blame' falls on me. However, I'm somewhat at a loss. What newlines are missing?

I don't know if the fact that I'm working on MacOSX plays a role, or perhaps rather that I've not been able to get the translation tools to work. I've saved the file with Unix newlines and UTF-8 (no bitorder mark) encoding, and as far as I can see it works fine in-game.

I know that I've not added newlines after the actual words in the defines, since that newline (at least when I started to translate some versions ago) showed up in-game. Is this the problem?

Sorry to be a nuisance, but I would reallly like to get the translation in working order! Not that I'm at all sure that I can get the migration tools to work on the mac either.

[yann]

The merge has happenned. 0.8.3-CVS now uses gettext. I hereby declare the rush for initializing pofiles open !

Note that hungarian, polish, and swedish catalogs do not build because of too many missing newlines in their translations. I'll let the respective teams take care of this.

Since I've submitted the last swedish translation, I guess the 'blame' falls on me. However, I'm somewhat at a loss. What newlines are missing?

I've not looked precisely, just follow the errors given when compiling the unfuzzed po files.
In a couple of other languages, where there were only one or 2 errors, I fixed them and found they all were in scenario objectives, which often start with a newline.

[MadMax]

Do user-made campaigns have to be converted to gettext? I already took the plunge and converted my campaign into gettext. Do I have to convert it back?

[sanna]

Is this the place to report where unwitting double use of same id causes translation problems?

Code: Select all

#: data/translations/english.cfg:394 data/units/General.cfg:3
#: src/preferences.cpp:869
#, fuzzy
msgid "General"
msgstr "Allmänt"

i.e, the General and General settings have same id

[Viliam]

Is this the place to report where unwitting double use of same id causes translation problems?

I don't know, but I will add another: Ogre (unit id), Ogre (scenario id, "Ogre Training" in Eastern Invasion).

[Dave]

What is the status of this translation effort?

As far as I can see, many things are still undone. E.g. difficulty levels are not displayed properly, even in English.

David

[yann]

Do user-made campaigns have to be converted to gettext? I already took the plunge and converted my campaign into gettext. Do I have to convert it back?

The framework for this is not yet in place, I'll work on it soon - it should not take too much work to do.

[yann]

Is this the place to report where unwitting double use of same id causes translation problems?

If they must be translated in a different way, the english strings should be prefixed with some description, separated from the string by a | character.
Eg: "menu name|General"

The prefix should _not_ appear in the translated strings.

I don't know, but I will add another: Ogre (unit id), Ogre (scenario id, "Ogre Training" in Eastern Invasion).

Id's are not translated. Only tagged strings (unit name, scenario name, ...) are translated. That's _the_ reason why units now have an id, BTW.

[yann]

What is the status of this translation effort?

Basically, all areas in the current code that still call the old API (translate_string, string_table) are not done. My initial idea was to change things to be more in the gettext way (ie. strings closer to where they are used), but I think it'd be more efficient to read english.cfg again. I'll modify language.cpp for this now. This should fix most of the remaining issues, and we'll see later if we can make things cleaner.

As far as I can see, many things are still undone. E.g. difficulty levels are not displayed properly, even in English.

There was a problem when selecting the difficulty when starting a campaign, which I fixed several days ago. But there is still a problem when the "load" dialog displays it, which I noticed recently. Is there some other places tha I miss ?

[isaac]

Tools to work with gettext

I suppose GNU/Linux users already know how to work with gettext .po files.

They can use Emacs or vi to do the job, optionally with a helper mode or set of macros.

At least there are other two applications to help with .po translations in Linux, kbabel and gtranslator.

There also exists a cross-platform tool, called poedit
http://poedit.sourceforge.net/, which works in both Linux and Windows.

Best regards

[Dave]

I believe this bug: https://savannah.nongnu.org/bugs/?func= ... m_id=10065 is related to gettext and making units rely on IDs instead of type names, yes?

David

[Dave]

So, who is doing the remaining work on the gettext integration? yann? isaac? Ayin?

Am I needed to help with anything or implement anything?

We don't necessarily need to rush things, but we do need to have a clear idea of who is doing what. I am not willing to wait an indefinite time for the next release because there are features that need to be written that aren't clearly assigned to anyone.

David

[Viliam]

Id's are not translated. Only tagged strings (unit name, scenario name, ...) are translated. That's _the_ reason why units now have an id, BTW.

I expressed it incorrectly. This is what I meant:

data/units/Ogre.cfg

Code: Select all

name=Ogre

data/scenarios/Eastern_Invasion/Ogre_Training.cfg

Code: Select all

id=Ogre

Both of these lines result in the following line in translation files:

Code: Select all

Ogre="..."

What is written in, is used both as name of "Ogre" unit, and as a title of "Ogre Training" scenario.

[sanna]

If they must be translated in a different way, the english strings should be prefixed with some description, separated from the string by a | character.
Eg: "menu name|General"

The prefix should _not_ appear in the translated strings.

Yes, they must be translated in different ways. These prefixes, should they be added by the developers, or is it something translators should do?

I guess some of the confusion is due to the fact that I'm unsure of whether the po-files are use in-game, or only to generate valid translation/|language|.cfg files. Which is it?

Also, in the po-files, most msgid are split up on several rows, with each row within quotation marks, while in the msgstr:s only those translations acutally containing newlines seems to have been split up in this way. Is this intentional? Is it OK for translators to split up msgstr:s in the same way that the msgid:s are split?