mixed locales after loading savegame

Bug #1800565 reported by Toni Förster
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
widelands
Won't Fix
Low
Unassigned

Bug Description

The setup is as follows:

Client 1: local set to german

Client 2: local set to english

Client 1 saves the game and both Clients exit to the Menu.

Client 1 hosts a new game loaded from the aforementioned save file.

Client 2 receives the savefile from Client 1 and the game starts.

All messages in the Inbox/Archive are in German instead of English on Client 2. Also the status messages for building (like, produced coal) are in German) until they get updated.

See the attached screenshot.

Revision history for this message
Toni Förster (stonerl) wrote :
Toni Förster (stonerl)
description: updated
Revision history for this message
Toni Förster (stonerl) wrote :
description: updated
description: updated
Revision history for this message
Benedikt Straub (nordfriese) wrote :

As I understand it, the problem is that strings that are stored in savegames are saved localized.
Easier way to reproduce: Start a savegame, save it, change the language, load it, and the strings are messed up. Especially in scenarios (story messages and objectives are always in the language in which the game was first started).

Revision history for this message
GunChleoc (gunchleoc) wrote :

The problem here is that strings coming from the win conditions and from the scenarios get assembled via Lua freely. This means that not only the English string, but the complete algorithm on how it was assembled would need to be sent to C++ - I don't think that this is doable.

We might be able to handle the engine messages coming from the tribes though with some additional metadata.

Changed in widelands:
importance: Undecided → Low
status: New → Confirmed
tags: added: internationalization
GunChleoc (gunchleoc)
summary: - mixed locals after loading savegame
+ mixed locales after loading savegame
Revision history for this message
Benedikt Straub (nordfriese) wrote :

Instead of translating strings immediately on calling _(), they could be tagged as "translatable", stored in English with this tag all the time and only translated for displaying by the font renderer. This might be a very large change though, and I don´t know how the tagging should be handled. Perhaps as a new struct Translatable which encapsulates a const char* or std::string and replaces these as data type for strings that should be translated?

Revision history for this message
GunChleoc (gunchleoc) wrote :

This will not work. We assemble complicated strings before sending them to C++.

Example from win conditions:

         descr = descr .. h2((_"Status for %s"):format(plr.name))
         local points = 0
         for idx, ware in ipairs(point_table[plr.tribe_name .. "_order"]) do
            local value = point_table[plr.tribe_name][ware]
            local count = 0
            for idx,b in ipairs(bs) do
               count = count + b:get_wares(ware)
            end
            local lpoints = count * value
            points = points + lpoints

            local warename = wl.Game():get_ware_description(ware).descname
            -- TRANSLATORS: For example: 'gold (3 P) x 4 = 12 P', P meaning 'Points'
            descr = descr .. li(_"%1$s (%2$i P) x %3$i = %4$i P"):bformat(
               warename, value, count, lpoints
            )
         end
         descr = descr .. h3(ngettext("Total: %i point", "Total: %i points", points)):format(points)

Example from scenarios:

      li(_"Build a coal mine and an iron mine.") ..
      li_arrow(_"To do so, place a flag up on the mountain’s flank to the east (on mountain terrain though, not mountain meadow). When you click on the new flag, you can send geologists there. Because the flag is on a mountain, the geologists will search for ores; otherwise, they would search for water. Then build a mine for both kinds of resources that they will find, choosing the appropriate mine to be built:") ..
      li_image(wl.Game():get_immovable_description("barbarians_resi_coal_1").representative_image, _"a bit of coal") ..
      li_image(wl.Game():get_immovable_description("barbarians_resi_coal_2").representative_image, _"a lot of coal") ..
      li_image(wl.Game():get_immovable_description("barbarians_resi_iron_1").representative_image, _"a bit of iron") ..
      li_image(wl.Game():get_immovable_description("barbarians_resi_iron_2").representative_image, _"a lot of iron") ..
      li_image(wl.Game():get_immovable_description("barbarians_resi_gold_1").representative_image, _"a bit of gold") ..
      li_image(wl.Game():get_immovable_description("barbarians_resi_gold_2").representative_image, _"a lot of gold") ..
      li_image(wl.Game():get_immovable_description("barbarians_resi_stones_1").representative_image, _"a bit of granite") ..
      li_image(wl.Game():get_immovable_description("barbarians_resi_stones_2").representative_image, _"a lot of granite") ..
      li_image(wl.Game():get_immovable_description("barbarians_resi_water").representative_image, _"water") ..
      li_image(wl.Game():get_immovable_description("barbarians_resi_none").representative_image, _"nothing was found here") ..
      p(_[[Mines can only be built on mountain terrain. Suitable places for mines are displayed as orange mine symbols.]]))

Revision history for this message
GunChleoc (gunchleoc) wrote :
Changed in widelands:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.