Immovable attribs (e.g. stone) are not translatable

[Dirk Stöcker]

I proposed a branch for merging, which fixes some I18n bugs.

Revision 6383 is uncritical,
http://bazaar.launchpad.net/~stoecker/widelands/fixes/revision/6383
Revision 6384 is more a guess how the issues should be fixed.
http://bazaar.launchpad.net/~stoecker/widelands/fixes/revision/6384

Please consider either merging the branch or copying the fixes to the code in any other form.

https://code.launchpad.net/~stoecker/widelands/fixes/+merge/105307

[Nasenbaer (nasenbaer)]

> Revision 6384 is more a guess how the issues should be fixed.
> http://bazaar.launchpad.net/~stoecker/widelands/fixes/revision/6384

Did you compile and test whether it works?

res_type is an attribute of an object and thus not translateable - you are still right that this should be fixed, but a correct fix would be to define a translateable name for each attribute globally and to use it in the message.

f.immovable.name is the name of the directory of the building and thus not translateable as well. Again you are right, that it should be fixed, but the right fix would be to implement a lua function that returns the descriptive name and at best already translated.

I am not sure about your changes in rev 6383, as I am not that deep into lua. Were those lines untranslated without those changes?

Please do not get me wrong - it is very good, that you start to tackle this bugs. it's just that it is not yet ready to be merged, as it does not have the intended behaviour.

[Dirk Stöcker (stoecker)]

> Did you compile and test whether it works?

No. I did not compile it as I have no working environment and not enough time to care for one. These are a suggestion and clearly marked as suggestion. But are you sure that it does not work? Gettext simply uses a text table lookup. So when there is a translation for the text (which is for building names), then a call to the translate function should translate it. Only issue could be the different translation contexts you use in widelands which complicate things.

> I am not sure about your changes in rev 6383, as I am not that deep into lua. Were those lines untranslated without those changes?

These changes are requires. The commit comment tells you why.

[SirVer (sirver)]

> These changes are requires. The commit comment tells you why.
If they aren't picked up by lua-gettext.py it is more a bug in it. I am grateful for your proposed fix, but the real fix is to fix lua-gettext.py. I changed this bug report accordingly.

About the second issue: peter is right, this needs to be fixed in lua by adding a property that returns the descriptive name of a ware or worker. .name is the internal name which is not translated in all cases and should not be translated because it is also used as key to tables here and there.

[Dirk Stöcker (stoecker)]

> If they aren't picked up by lua-gettext.py it is more a bug in it. I am grateful for your proposed fix, but the real fix is to fix lua-gettext.py. I changed this bug report accordingly.

You may modify the gettext system either that also inside the software the trailing character is stripped as well (looks better) or that the text extractor for translation adds the character also (cleaner design).

Nevertheless the patch should be applied, as the additional character is obsolete and should not be there (all other strings don't have it). And even the displayed English texts looks (a bit) ugly due to this one. The patch simply will match the internal representation with the correct translated ones.

[SirVer (sirver)]

Quick update: I fixed the lua-xgettext.py script so that it no longer eats the last newline. I also added a descname property to lua objects and fixed the atlanteans buildings lost message.

The only remaining thing it the resource thingy in
http://bazaar.launchpad.net/~stoecker/widelands/fixes/revision/6384.

I have not looked into that yet.

[SirVer (sirver)]

Oh, I also applied Dirks patch to remove unnecessary newline characters from the strings. Thanks Dirk!

[SirVer (sirver)]

I just committed a patch that will look up the name of resources in the earth (coal, iron, and so on) before the message is delivered to the user. There are still problems with attribs (e.g. stone) because there is no translation for them in the world configuration.

The ideal solution (imho) would be if the buildings sends the message itself. That would be trivial if the building programs were Lua programs -- which I am still a supporter of.

[SirVer (sirver)]

One possible solution is to collect all attribs on parsing time and save the translations in the world. the world config would need a new section

[attributes]
stone=_Stone
tree=_Baum

which would make things translatable. However, this still feels suboptimal to me.

[Dirk Stöcker (stoecker)]

> I just committed a patch that will look up the name of resources

You did? I don't find it anywhere.

I don't know your translation infrastructure very well, but for JOSM we have lots of different file types with translatable strings.

We have converter programs for each type which convert these strings into a pseudo-code-file which is then parsed by the string extractor.

[SirVer (sirver)]

>You did? I don't find it anywhere.
forgot to push. Sorry.

We have something very similar: scripts that parse conf and lua files
and extract strings in gettext format. Problem is just that the word
"stone" is never translated inside the world textcatalogue.

[Dirk Stöcker (stoecker)]

For these cases we have a "special texts" file. It contains any translatable string which forever reason never appears somewhere else. Thought such file tends to be outdated after some time, but the drawback of a few additional obsolete translations is acceptable.

[SirVer (sirver)]

Setting to incomplete for bug sweeping.

[wl-zocker (wl-zocker)]

In r6970, "stone" and "fish" are translated. Will this be broken by the one_world branch or why was it set to "incomplete"?

[GunChleoc (gunchleoc)]

The fix I did to make them translatable is an ugly hack I did in C++, because internally it is still "granit" for the stone resource. So, replacing the ugly hack with clean code after the one_world merge would still be a useful improvement :)

[GunChleoc (gunchleoc)]

Fixed in build19-rc1.