Some variables are not translatable

Bug #682405 reported by Hans Joachim Desserud
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Fix Released
Low
Unassigned

Bug Description

An example:
The message sent to a player when for instance a quarry runs out of stone is this:
https://translations.launchpad.net/widelands/trunk/+pots/widelands/nb/352/+translate
which corresponds to the following lines in src/logic/worker.cc
        building.send_message
                (game,
                 "mine",
                 _("Out of ") + res_type,
                 std::string
                        (_
                         ("The worker of this building cannot find any more resources "
                         "of the following type: "))
                 +
                 res_type,
                 1800000, 0);

While the message itself is translated and shown in the correct language, the name of the ware is shown in English no matter what. I assume this is since it uses the value from the variable, which isn't translated. While it is obvious that the quarry has run out of stone, since that's what it's producing, the message ends up mixing languages which seems a bit strange.

I believe the same issue affects loading of a map, when it shows which tribe is loaded:
loading tribe: barbarians

Would it be possible to translate variables such as these? I understand from the way out of resources checks wares, it needs to use the internal name, but it could perhaps be translated before it is presented to the end user? I'm not sure if this can actually be fixed in an easy way, but by filing this report it's a known issue at least.

Related branches

Revision history for this message
Timowi (timo-wingender) wrote :

variables can be translated just as any string. Just pass the variable to _() or directly to i18n::translate(). I am not sure what happens with string extraction if _() is used there but i18n::translate should work fine.

Revision history for this message
Hans Joachim Desserud (hjd) wrote :

Timowi: thanks, I didn't know that.
I got a working proof-of-concept which I can probably turn into a proper patch. However, I am bit busy these days, so it may take some time.

Changed in widelands:
assignee: nobody → Hans Joachim Desserud (hjd)
status: New → In Progress
SirVer (sirver)
Changed in widelands:
importance: Undecided → Low
Revision history for this message
Hans Joachim Desserud (hjd) wrote :

Ok, it turns out this was slightly harder than I imagined. I have have made some attempts, but haven't really gotten any further than the attached branch. I've tried a few different approaches to get it to work, but nothing seems to be moving forward. Therefore I'll revert the status to 'Confirmed' and make it no longer assigned to me, so at least I'm not blocking it if anyone else wants to work on this.

While searching for other places where variables are made translatable, I found an example in src/logic/production_program.cc, where the translatable warename is fetched based upon a ware index ( tribe.get_ware_descr(ware_type)->descname(); ). However, in this case the ware_type is an index, whereas the ware in the out of resources message is a string, so if it can be used it needs to be adjusted in some way in order to work.

Changed in widelands:
assignee: Hans Joachim Desserud (hjd) → nobody
status: In Progress → Confirmed
Revision history for this message
Shevonar (shevonar) wrote :

I found this old bug when I just wanted to report part of it as a new bug. I recently recognized the "loading tribe: barbarians" problem. For this specific problem I would suggest to remove the tribe name completely because of the new random tribe feature. If you choose random tribes (in a one on one game) you could figure your enemy's tribe out by just looking closely at the loading bar. That is against the idea of the random tribe feature and I think it is not really important which tribe is loaded currently (especially because it doesn't take long).

Revision history for this message
SirVer (sirver) wrote :

I agree with #4

Revision history for this message
Angelo Locritani (alocritani) wrote :

I found this bug while trying to report the same behavior.

Regarding the _("Out of ") + res_type message, I found that res_type is not the name of a ware but simply the attribute of a map object ("stone" for example) - see Map_Object_Descr::get_attribute_name (src/logic/worker.cc:392).

Attributes seems to be not translatable, at the moment.

Revision history for this message
Shevonar (shevonar) wrote :

In revision 6288 I removed the tribes names from the progress bar when loading a game. I didn't change anything in the editor loading screen, because it seems to be bugged anyway (see bug #536324).
I also didn't change the out of resource message, because I couldn't figure out a proper way to fix this. On the one hand the attributes should be dynamical (you can use anything as attribute, there are no limitations), on the other hand they should be translatable. That doesn't fit and one of these features must be dropped. I suggest dropping the "dynamical feature", because I think there is just a limited number of attributes that are really necessary.

Revision history for this message
Nasenbaer (nasenbaer) wrote :

The fix for this bug is most probably related to bug 948817 - as soon as we decided how to handle the problem of messages in general, we can decide about the specifc message bug described in this report.

Changed in widelands:
milestone: none → build-18rc1
Revision history for this message
Angelo Locritani (alocritani) wrote :

this seems to be related to Bug #999262, too

SirVer (sirver)
Changed in widelands:
milestone: build18-rc1 → build19-rc1
Revision history for this message
GunChleoc (gunchleoc) wrote :

This is partially fixed now with a little hack. The current behaviour is like this:

- Widelands gets the resource type from the world, creating a message header like this.

if stone: _(Out of Stone)
else if fish: _(Out of Fish)
else : _(Out of Resources)

The message body displays a longer string, which still contains the resource name - From worker.cc:
"The worker of this building cannot find any more resources "
     "of the following type: %s"

Now, what happens that the parameter passed to the function is

- "Fish", in title case, which results in "Out of Resources" and a localized resource name in the message body, or
- "stone", in lower case, which results in "Out of Stone" and an unlocalized resource name in the message body.

On another note, it would also be nice to get the name of the building into the string.

- Mining resources and water have a different, generic message subject anyway. Their message body displays an image for the resource type.

Revision history for this message
Hans Joachim Desserud (hjd) wrote :

So the messages should now be translated, except for "stone"? Why is that lowercase, anyone know? Is it due to different tribes having different resources? I discovered in the translation dictionary that there's Raw Stone, Stones and Stone, depending on which tribe you play.

Revision history for this message
GunChleoc (gunchleoc) wrote :

The problem is that the value passed to this function is defined in the worlds and not the tribes. Changing that is way over my head and somebody else would need to take this on.

Alternatively, we could rename the resources in the tribes. It's the same resource really, So I wouldn't see a problem with that.

According to the conf files, raw stone/stones/stone isn't turned into any other building material. However, Imperials cut and mine both Stones and Marble from stone on the ground or in mountains, and Atlanteans mine Stone and jewels from stone in mountains.

These messages are only used for stone on the ground, the message for missing stone in mountains is handled by an image.

I'd rather like renaming the tribes' resources to "granite blocks", but this doesn't solve our problems here, because of the Imperial economy also getting marble from the resource. Maybe we could use an image here as well, rather than text?

GunChleoc (gunchleoc)
Changed in widelands:
assignee: nobody → GunChleoc (gunchleoc)
status: Confirmed → In Progress
Revision history for this message
SirVer (sirver) wrote :

Is this fully done now?

Revision history for this message
GunChleoc (gunchleoc) wrote :

Yes :)

Changed in widelands:
status: In Progress → Fix Committed
GunChleoc (gunchleoc)
Changed in widelands:
assignee: GunChleoc (gunchleoc) → nobody
GunChleoc (gunchleoc)
Changed in widelands:
status: Fix Committed → Fix Released
Revision history for this message
GunChleoc (gunchleoc) wrote :

Fixed in build19-rc1.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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