Update wesnoth-utbs.po

[MultiSeptim]

ke commit b810cc6

[MultiSeptim]

Obecně ale nejsem nadšen těmito typy změn. Dávat do textů jména jako proměnou vždy komplikuje překlady. Chtěl bych vidět, jak se s tím popasují jazyky, které nepoužívají latinku. To bude jako v textu v azbuce jméno latinkou?

[celerini]

It may be worth to explain our translation difficulties (as I tried earlier) to the author of this change and ask him directly.

[Wedge009]

What's the issue here? With respect to wesnoth/wesnoth#6165, which involved @stevecotton, @CelticMinstrel, and myself, the intention was simply to remove the redundant duplication of strings. However simple it might be translate duplicate strings, I think it best to avoid them in the source for similar reasons that we avoid redundant duplication in code. Is the issue solely to do with variables that are included within the translated text or is it something more?

[MultiSeptim]

Yes it does. Strings with variables may be difficult to translate.
I reacted to the latest changes in UtBS (main). I dealt with them, but it wasn't easy. Somewhere I had to omit those names from the translation, for example, I used phrase a dwarf/troll friend instead of $ally_unit.name.
I agre that code should be clean. But I haven't registered that $ally_unit.name could be varied somewhere yet (e.g. due to declension).

[Wedge009]

If I recall correctly, it can be tricky for troll speech because in English speaking in the third person can be interpreted as a sign of low intelligence, and trolls are often characterised this way. Hence sentences like 'Grog promised to help little dwarves' - but 'Grog' is just replaced with the variable name instead (because the troll could be replaced with one of another name).

I'm neither a linguist nor multi-lingual, so pardon me for not fully understanding but is there something more complex to consider than just substituting names for the variable names when reading the lines for localisation? I should add that this isn't a problem unique to the refactoring - it could potentially be present in other campaigns where variables are used.

[MultiSeptim]

It's not so "complicated", it's just how to handle variables well for translation. And yes, this is a very general problem. We figured it, for example, in WC.

[celerini]

We (Czech) are changing (mainly by adding a suffix) nouns (adjectives, pronouns...) according to their gender, grammatical paradigm (pattern, type) and grammatical case (context). Although the case (context) is known from surrounding text, both the gender and the paradigm is not known when using variables. So we can't append the correct suffix to the variable and thus all such translations looks dumb as if it would be a troll speach.

English is simpler than Czech (thus you can deduplicate a text in same manner as a code), but has its own remains of the grammatical case. Consider he - I see he (not him) may look similar in English as when we use a plain variable name in Czech.

I think it can be overcome by using generators, but not for a sake of simplicity. Please se my previous comment.

Is it more clear now?

[Wedge009]

For the specific case of UtBS, where these dwarf and troll allies are concerned, they are always male.

Edit: I see this example of pre-existing use of a variable name. Does the translation simply drop the reference? (In English, that would be valid.)

wesnoth-cs/wesnoth-dw.po

Lines 2381 to 2388 in a543abd

	#. [message]: speaker=Kai Krellis
	#: data/campaigns/Dead_Water/scenarios/10_The_Flaming_Sword.cfg:274
	msgid ""
	"Thank you, $spy_unit.name|. I will keep that in mind, but it may be hard for "
	"us to stop him with that teleporting trick he has."
	msgstr ""
	"Děkuji ti. Budu na to myslet, ale může být pro nás těžké ho zastavit, s těmi "
	"jeho teleportačními triky."

Edit 2: This translation appears to show no difference between a reference to a male unit and a female unit - is that correct?

wesnoth-cs/wesnoth-httt.po

Lines 7291 to 7299 in a543abd

	#. [message]: speaker=$unit.id|
	#: data/campaigns/Heir_To_The_Throne/scenarios/20b_Underground_Channels.cfg:612
	msgid "Should $unit.name| read the book?"
	msgstr "Má si $unit.name| přečíst knihu?"
	#. [message]: speaker=$unit.id|
	#: data/campaigns/Heir_To_The_Throne/scenarios/20b_Underground_Channels.cfg:613
	msgid "female^Should $unit.name| read the book?"
	msgstr "Má si $unit.name| přečíst knihu?"

[CelticMinstrel]

I get the issue. It's easy to forget that nouns (even proper nouns) decline in some languages, and I don't even have the excuse of not being a linguist or multilingual. Although it's unfortunate, given the effort @Wedge009 and I put into that pull request, the simplest solution to this problem is likely to just revert it. Looking at it, as far as I can tell it didn't include any other changes beyond the string deduplication.

That said, this pull request (which seems unrelated?) probably isn't the best place to discuss it. I might've missed the whole conversation if I hadn't misclicked my notifications.

[MultiSeptim]

In the first example, the name (noun) is in the fifth case. So variable will not work properly.
In the second example, the name (noun) is in the first case. So variable could work (male and female too), except the situation when we translate the name also (like Conrad -> Konrád).

[Wedge009]

That said, this pull request (which seems unrelated?) probably isn't the best place to discuss it. I might've missed the whole conversation if I hadn't misclicked my notifications.

I replied here, because the question was put to me directly in the Wesnoth issue report (not the PR) relating to the text consolidation. Are you saying that you're in favour of reverting that work? I'm uncomfortable with having all that duplication for the reasons we worked on the PR in the first place, plus I was reviewing the changes to see if po hints could be added to assist.

In the first example, the name is in the fifth case. So variable will not work properly. In the second example, the name is in the first case. So variable could work (male and female too), except the situation when we translate the name also (like Conrad -> Konrád).

I appreciate that. The point of the examples I listed was to point out that the challenges you're facing with variables is a general translation difficulty, not specific to the UtBS consolidation we did.

[CelticMinstrel]

In the first example, the name (noun) is in the fifth case. So variable will not work properly.
In the second example, the name (noun) is in the first case. So variable could work (male and female too), except the situation when we translate the name also (like Conrad -> Konrád).

Even if that's true for one language, I don't think I can guarantee it's true for every supported language.

Are you saying that you're in favour of reverting that work? I'm uncomfortable with having all that duplication for the reasons we worked on the PR in the first place, plus I was reviewing the changes to see if po hints could be added to assist.

I don't like seeing duplication either, but as this exact issue shows, deduplication can hurt localization. I think a localization system could theoretically be made that handles this automatically, but gettext is not that (and I don't believe one exists), so unless you can come up with a better idea, then… yes, I am reluctantly in favour of reverting it.

[Wedge009]

Have reverted the text consolidation and re-opened the associated issue.

[CelticMinstrel]

The associated issue is wesnoth/wesnoth#6158.