Missing translations

[Dirk Stöcker]

I don't understand the software structure fully, but I'm pretty sure following 3 fixes must be done :-)

[Dirk Stöcker (stoecker)]

Found 3 more.

[Hans Joachim Desserud (hjd)]

Seems right to me. I'm currently unable to find any of the strings mentioned in the patch when searching in translations.

[Nasenbaer (nasenbaer)]

Jundlina is a name, so this should not be translated - the others seem right.

[Dirk Stöcker (stoecker)]

I unified it. "Jundlina" is translated at other places.

[SirVer (sirver)]

Thanks, applied in 5749. Should be translatable on site by tomorrow.

[Dirk Stöcker (stoecker)]

I attached another patch fixing some translation issues.

Another problem: In

campaigns/atl01.wmf/scripting/init.lua line 77 is wrong:

         (_"We lost a %s to the ocean!"):format(f.immovable.name)

The f.immovable.name is the internal name of an object including "_". It should be replaced by the human readable text and also by the translated one.

Also I think when sinking starts a new note would be helpful, that a warehouse in the hills is a good idea and also that moving essential stuff like tools, people and wood to this new warehouse seems sensible.

[SirVer (sirver)]

I applied your patch.

the thing with the internal name is a known issue and needs quite some Lua stuff to change to be done properly, therefore it is a won't fix for now. Please open a new bug report for this if you care.

I disagree on the note. Some things must be left to the player to decide and it is kinda obvious.

[Dirk Stöcker (stoecker)]

And another one - Sorry for the step-by-step, but I can't play the whole game at once :-)

Regarding the internal name problem:

I would rather fix it now - It gets harder by the time and especially hard will be to get rid of workarounds which come step-by-step :-)
Can't the object also contain the translated name beside the internal name?

Regarding the note: It is a tutorial, isn't it? Maybe not too obvious - something like this: "I hope the required materials can be saved until the shipbuilder requires them"?

[Dirk Stöcker (stoecker)]

In src/ui_fsmenu/launchMPG.cc: 586

The following parts aren't displayed German. For me it looks right, so I can't fix it.

        std::string infotext = _("Map informations:\n");
        infotext += (format(_("* Size: %ux%u\n")) % map.get_width() % map.get_height()).str();
        infotext += (format(_("* %i Players\n")) % m_nr_players).str();

        // get translated worldsname
        std::string worldpath((format("worlds/%s") % map.get_world_name()).str());
        Profile prof ((worldpath + "/conf").c_str(), 0, (format("world_%s") % map.get_world_name()).str());
        Section & global = prof.get_safe_section("world");
        std::string world(global.get_safe_string("name"));
        infotext += (format(_("* World type: %s\n")) % world).str();

The "map.get_world_name()" is translated, but the direct texts "Map informations:\n", "* World type: %s\n", "* %i Players\n", "* Size: %ux%u\n" are not, although there are translations for these in the translation files.

[SirVer (sirver)]

#12: They are likely not translated because the translation branch has not been merged into trunk for a while. If they are on launchpad and tagged in the source, the will be translated later on.

I applied your other patches as is. Thank you.

[Dirk Stöcker (stoecker)]

@SirVer: No. I use up-to-date translations and latest branch. There have been no translation changes in the days before in this area of code. There IS an error there. Probably one of the reasons, where functions are called before translation is initialized or wrong translation file loaded or something like that. I fixed lots of other errors in translations directly, but this needs work in the code and I don't have the time to experiment to find out the structure.

This is not the first software, where I have a deep look at translation issues. In every software I found such problematic cases until now, so I assume widelands will not be the different :-)

P.S. An update of translations in source would nevertheless help. It would ease making the RPM's, as usually too patchy code is not acceptable. I wanted to ask for this when I found and fixed most problems I could see.

[SirVer (sirver)]

Dirk, you are right. I attempted a fix in r5757. Could you please check?

[Dirk Stöcker (stoecker)]

No. In r5763 the problem still exists.

[Nasenbaer (nasenbaer)]

#12 was fixed by me some revisions back

[SirVer (sirver)]

Released in build16-rc1