Topic: Repeating Strings vs. Individual Strings in game code [Discussion]

[Leartin]

This is a discussion started in some Patch threads. The basic question: Should the game reuse strings or not?

Individual Strings have the advantage of being more flexible. Translators could translate knowing exactly where the string is going to be used, specific for that situation. The downside is more strings to translate, with a lack of translators to do so.

Repeating Strings have the advantage of having less strings in general, and new features can be implemented fully translated to each language, so long as the strings used already exist. However, the system is more rigid and does not allow for any diversion from the given base string, as that might not fit elsewhere the string is used (or will be used in the future)

I'd like this issue to be discussed here, since it's kind of important to know for anyone who wants to write patches or wants to translate. Any patchwriter should know whether they should 'try and reuse old strings' or 'try and make unique strings that won't accidentially overlap'. Any translator should know whether he can use words or a phrase that fit perfectly for the situation he sees the string used, or should rather try to use more general translations just in case the string gets reused.
Besides, if translations should strictly follow the base string, what about base strings that turned wrong by changes to how the game works?

I'm not sure a concensus can be reached, but it's certainly better to talk about it rather than programmers and translators being mad at each other for making the others job harder.

[prissi]

To add to this:
In the past strings were recycled whenever possible, since a new string is not translated for years in most languages, despite Simutranslator. The languages that are pretty complete are English, German, Japanese, and Czech. The rest depends often on the activity of a single member in the community.

[Leartin]

I absolutely get this idea. What I don't understand is why it has to be "Let's reuse StringX" rather than "Let's use a new StringY and make it a copy of StringX". The game would be just as translated that way - technically even more translated if a translation for StringX existed, since you add a new translated string

Meanwhile, I'm certain there are a bunch of strings, especially single words, that should be reused - simply because even if they could be translated in several ways, they simply shouldn't as long as they refer to the same game object. To use a German example: It really doesn't matter if it's called "Fahrgast" or "Passagier", but it should always be the same word, else it becomes confusing.

---snipped some more examples for mistranslated multi-purpose strings---

[Andarix]

.... The languages that are pretty complete are English, German, Japanese, and Czech. The rest depends often on the activity of a single member in the community.

https://simutrans-germany.com/wiki/wiki/en_translate_base_texts

[Vladki]

I think that some consideration has to be done. If there are 10 dialogs that offer sorting of some list, then the label "sort by:" followed by combo box should be the same translation string.
But there may be situations where English can use the same literal string for verb, noun and adjective, while other languages have slightly different forms, or depending on context use totally different phrase.
Example: "retire".  It may be a string on the button, where it is a verb - command to retire a convoy (sell/send to depot when empty), or it may be a part of vehicle information in "retire date", which means end of production. While in English the word "retire" would be acceptable in both situations, it won't work in Czech.

Is it possible to pre-fill the translations of new strings by translation of already existing similar string? That would be helpful to avoid unnecessary extra work.

Anyway there is lot of duplicate work needed - pakset translations. The have a lot of shared strings which need to be translated over and over: e.g. factories and goods. Is there anything in simutranslator that would help - like search the same string over all paksets and mark the translation to be used in all others?

[Andarix]

....
Anyway there is lot of duplicate work needed - pakset translations. The have a lot of shared strings which need to be translated over and over: e.g. factories and goods. Is there anything in simutranslator that would help - like search the same string over all paksets and mark the translation to be used in all others?

since 20 April 2014

https://forum.simutrans.com/index.php/topic,687.msg134478.html#msg134478

But that's useless if Pakset developers are of the opinion that everything should be named differently. As pak128.german and pak192.comic do.

[Ters]

This question has bothered me for years at work. It is perhaps unrealistic for a developer to know every rule in every language that has to be consideration in order to know whether the same text can be used in different contexts. And it gets worse when the text is combined with a dynamic value. Suddenly the text depends on the values gender, number, person, direction of movement, and so on. At least the translation framework I work with, let the translator add case-expressions (programmatical cases, not grammatical cases) to the translation that is evaluated at runtime. I don't have the impression Simutrans is that advanced.

My current impression is that this just has to be worked out between developer and translator over time. Planning ahead takes too much time. As does making all texts single-use, which also increases the size as well. However, it is important that all translations get fixed if a string must be split into two. That is, adding a new variant of a preexisting translation must work differently from adding a completely new translation. When splitting, any original translation in each language should be copied as well.

[ampersand]

I am happy this discussion has been started, although I have not translated much. I could say a lot on all that's been written above, but I understand this is not on all that can be said on translation in general.

I second:

• cooperation is more difficult without clear structural guidelines

• other languages have slightly different forms

  , which favours the individual approach. Vladki has given a good example above, if you need more:
  You're mad = (Du bist verrückt || Sie sind verrückt || Ihr seid verrückt)

• as long as they refer to the same game object

Another particular opinion: if pakset creators care more for some things different than .tab file size, it's their choice. If they would like to reduce the file size and facilitate translation for other people, then may be a kind of peer-review should be enabled?

when the text is combined with a dynamic value.

was solved years ago and some programming languages already have incorporated the solution, which would favour the reusable approach. I have no idea if Simutrans can use this kind of solution.

[prissi]

I am well aware that different laungage have different fules, German is a good example of word changing ending at almost any occasion (and then there are the two plurals in Russian ... ) However, the translation system of simutrans is from 1997. At that time there were not even the gettext GNU libaries available. Otherwise this would have been a better option.

Usual simutrans translators are active for one month and then to be never seen again for most languages. And those events are sparse, less than one per year. Thus most languages does not have an active translator, but are still used by players. (Or at least downloaded from those countries.)

As for German, Simutranslator rules are using "Du" I am not aware what other languages have agreed on, but as above, there seems very little coordination on many languages, as active translators never overlap.

So the most scare resource are translators for almost any language which is not Japanese, German, or Czech. Since translators are missing most, reusing string in similar context is the imho only sensible way if you do not want to make worse and worse with every feature added for most loanguages.

[Leartin]

Since translators are missing most, reusing string in similar context is the imho only sensible way if you do not want to make worse and worse with every feature added for most loanguages.

Some options:
1) Whenever a new string gets added, if there is a similar string available, use that strings translations as initial value in the translator. Therefore, if the old, similar string was translated, the new one will be as well, but if the translation is somehow off, it can still be fixed.
2) Extend the translator class with some "static const char *translate(const char* str, const char* str2);". That function would try to translate the first string and return it if a translation is available, and if it isn't, try to translate the second string and return it if a translation is available, and if it isn't, return the first string untranslated. Thus we can use existing old strings as a fallback for untranslated new strings within the games code.
3) Allow further specification. Say we employ the special character '\t' (since I don't think it's used in Simutrans and shouldn't be in any existing translations). Translatable strings could append additional information seperated by '\t'. For example, in the vehicle dialog, it would say "translator::translate("Intro. date\tvehicle")" and in the building dialogs "translator::translate("Intro. date\tbuilding")". Both would try to find a translation for the full string, and if it isn't available, dial back by one \t and try again with the shorter, more general string. Hence if a language has some translation for "Intro. date" but not for the new strings "Intro. date\tvehicle" or "Intro. date\tbuilding" it will be translated. If a language has different strings for the two occasions (eg. in english: release date vs. construction date)  they can be optionally implemented.

The choice isn't exactly between "Create new strings that won't be translated" and "Relink to the old strings making them impossible to translate seperately". There are other possible solutions that could be explored, which keep and reuse existing translations just as well.

[Ranran]

I think if the situation is different, it is wise to separate the translations. The same English (or German) word may be different in another language. For example, there was a translated word "left" in Extended. Considering the Japanese translation of "left", there are two possible situations: "左" (eg, left side) and "残り" (eg, 100km left = 100km remaining from here). Worse this was the latter. Therefore, it was impossible to translate it into accurate Japanese. Because the order of numbers and text cannot be changed.
I mean, it should have been something like "%i km left". If you know that it will always be combined with numbers, it may be better to combine it with numbers, but if you want to separate the units for alignment, it may not be.
And it gets confused when left, which means "left side", is added. Fortunately, the meaning left was added as "Left".
It depends on the UI situation where the word is used in that way.

In this respect, it is unlikely that this will happen with standard because there are prissi who are multilingual and have some understanding of Japanese.
This is something we Japanese must be very grateful for, given that many steam games have ****-like Japanese translations. (It may even be lucky to have a Japanese translation)

However, it is unavoidable that a coder who knows only a single language (or same derived language) will not realize this fact. But from the translator's point of view, it's a fact to keep in mind when adding terms.


An example that bothers me is that there are two translations of the same word, one with: and one without. Recently, standard has also increased some such examples with edit ui. However, there are many such examples. (Also in entended)
But if we already have a translated word with ":" and you need text without ":" in the same situation, you need to add it. (´・ω・｀)
If the ":" is independent, we have to put the combined text in gui_label_t.
I think it may not be necessary to prepare two translations if the addition of ":" is optional.

Another issue. If its translation has line breaks, you must be careful when reusing it for labels.
Line breaks(\n) are valid for multiline text. However, line breaks cannot be used in "labels", and the second and subsequent lines disappear.
When assembling the UI with the new GUI engine, I tried to reuse an existing text translation into a label. Terms that already exist may sometimes have "\n" at the beginning. In that case, the label does not display anything. The blank label cast a mess on me. (´・ω・｀)
It should be noted that it can be caused by translation for each language.
If we still need the original, we must make a duplicate with the line breaks removed.


There is no plural change in Japanese(1 convoy..., 2 convoys vs 1編成, 2編成...). Many will not make that mistake, but the Japanese need to keep it in mind.

[prissi]

The gettext documentation suggests to use the whole string whenever possible, and I think this is a good idea in principle. (Same as using gettext, of course.) This fixes then also automatically "0 convois", "1 convoi" etc. issues. The prices would be again a lot of untranslated English text in the interim phase.

Before extending the built in functions, maybe considering gettext is the better choice. (Although, a major effort.) And then rather construct the translation strings during database transition from dumb Simutrans to gettext format.

[Leartin]

An example that bothers me is that there are two translations of the same word, one with: and one without. Recently, standard has also increased some such examples with edit ui. However, there are many such examples. (Also in entended)
But if we already have a translated word with ":" and you need text without ":" in the same situation, you need to add it. (´・ω・｀)
If the ":" is independent, we have to put the combined text in gui_label_t.
I think it may not be necessary to prepare two translations if the addition of ":" is optional.

Are there languages that don't use ":"? Else for these cases, the ":" could be excluded from translation and appended to the translated string. (Removing ":" in translations should be possible even if you don't speak the language)

Line breaks(\n) are valid for multiline text. However, line breaks cannot be used in "labels", and the second and subsequent lines disappear.

I don't think it's an issue, more like a feature for everything in Simutrans where there shouldn't be a lot of text. Check out the "build citybuilding" dialog in pak64. Some buildings start out with a short name like "Brickyard" followed by a newline and the description "This firm makes bricks and cinder blocks of various types and colors". In the list, such a building is stated as "Brickyard", since the list cuts at the newline. That works so well I'd argue that every translated citybuilding should follow the pattern <name><\n\n><description> for it's translation, as those that dont are just an annoyance in the list. (the translation rules mention that for curiosities - perhaps there just wasn't a "build citybuilding"-dialog back when those rules were written)
Same principle works for tooltips. You can have a long description about a road, since the tooltip won't show anything after a line break (see here: https://www.simutrans-forum.de/mybb/showthread.php?tid=9223) This, too, makes sense. I'm not certain labels need that (at this point in time), but I think eg. goods are always shown as labels. If someone were to translate a good as "coal\n\na combustible black or dark brown rock consisting chiefly of carbonized plant matter, found mainly in underground seams and used as fuel.", it probably wouldn't show up anywhere in the dialogs for factories or the goods list, but could show up in a hypothetical "good-info-dialog". If one had this idea waaaaaaay back, the seperate factory details translations wouldn't have been required.

The gettext documentation suggests to use the whole string whenever possible, and I think this is a good idea in principle. (Same as using gettext, of course.) This fixes then also automatically "0 convois", "1 convoi" etc. issues. The prices would be again a lot of untranslated English text in the interim phase.

Before extending the built in functions, maybe considering gettext is the better choice. (Although, a major effort.) And then rather construct the translation strings during database transition from dumb Simutrans to gettext format.

Maybe it is. But I'm not sure that's the case.
Say we decide to change to gettext and follow the gettext documentation on how to set up strings in the program. Then the lions share of the work is to change how the strings are set up. Else, it's pretty much repalcing translator::translate() with gettext() or _(). That's the programs internal side. From there, we'd have to decide - do we keep using the SimuTranslator? If yes, the simplest change is that .tab need to become .po and "msgid" as well as "msgstr" prepended to each line. But doing so doesn't add any new possibilities, we could only do the same things we can already do, just as much as the SimuTranslator allows. If no - how do we deal with pakset translations? Do we need a new SimuTranslator-esque tool that can read out dat files and create a ready-to-translate .po file from it? How could we automatically convey that "res_29" is a single-family suburban house with a swing in the garden to a potential translator, which wouldn't get an image or any other information from that .po file? Or would we use two systems in parallel?

Don't get me wrong - I'm not saying gettext is bad. But I'm not sure stuff like multiple plurals are a fair trade for the disadvantages we'd have, and changing the system doesn't really change anything about the question whether strings should be reused or not.

[Vladki]

Ranran has a good point about words that are the same in English but have multiple meanings and  different translation. Left and Right are very good examples. Not only Japanese. Czech has the same distinction between "left side" and "x km left" or "right side" and "public right of way".

And multiple plural forms are a completely different beast ;-(  (affecting all Slavic languages).

[Leartin]

Ranran has a good point about words that are the same in English but have multiple meanings and  different translation. Left and Right are very good examples. Not only Japanese. Czech has the same distinction between "left side" and "x km left" or "right side" and "public right of way".

Documentation for gettext about how to prepare strings within the program: gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#Preparing-Strings
They use the example "no match" and ask how the translator would know the program isn't trying to set something on fire, but can't since it lacks the tool. And there is no solution for that in code, they pretty much tell the programmer to use more meaningful strings such that the translator can grasp the meaning while translating. For the most part, the programmer does not need to speak other languages, they only need to know that the word they use has several meanings in English, and it shouldn't hurt to make that perfectly clear.

Though in Simutrans, an additional problem is that the programmer should use strings that look good in the game on their own, since any untranslated strings appear "raw". So that's another fallback we'd need - whenever there is no translation in the chosen language, use English translation. Which shouldn't even be hard to implement, just repeat if nothing was found?

Actually, I think my third suggestion from before (using tabs to make strings more and more special) could be used to solve the plural issue, kinda, by adding "\tone", "\tzero", "\two", "\few" or "\many".
Instead of calling translator::translate(string), call translator::translate(string, int). The translator would append the according suffix if the integer is in zero, one, two, few or many, where each of these five is a set, which depends on the current language (eg. in french, 0 would be in the one-set). Hence, you'd translate "You own %d vehicle(s)" as "You own %d vehicles" AND "You own %d vehicle(s)\tone" as "You own %d vehicle", but if "You own %d vehicle(s)\tone" has no translation, it falls back to "You own %d vehicles".
Since any strings with a tab are technically optional, the SimuTranslator shouldn't count them towards total translation and would have to treat them kind of seperate.

Anyway - what I intended with this discussion is basically to introduce guidelines like the ones gettext has for preparing strings. I think this needs to be the first step, since changing to gettext - if someone actually wants that - wouldn't get harder if our strings were already in the right format. Adding new translator features to account for plurals or gender wouldn't get harder if our strings were already in a better format. Only thing I think we really need is english as a fallback language for everyone, rather than raw text (which would be good anyway, to remove the old German strings from players sight entirely), and we need to be in agreement that we want to try and have meaningful strings that are easy to translate while treating the issue of too little translation activity as a separate one.

[Ters]

Ranran has a good point about words that are the same in English but have multiple meanings and  different translation. Left and Right are very good examples. Not only Japanese. Czech has the same distinction between "left side" and "x km left" or "right side" and "public right of way".

It is an example that probably would be rather obvious, although even obvious things sometimes slip by. The contexts they are used in are quite different.

"Vehicle" can be more troublesome. I can't think of any word in Norwegian that covers vehicles on land, on water and in the air, that it would not be very unnatural to use. Translated into English, it would be closer to "mode of transport". The German cognate is "Verkehrsmittel", which does not appear to be used to translate "vehicle". Even a common word for rail and non-rail vehicles feel unnatural. However, I am not sure how natural it is to use the word "vehicle" for a ship in English.

The gettext documentation suggests to use the whole string whenever possible, and I think this is a good idea in principle.

This would mostly fix the issue with "left" and "right", although there might be some cases where the words appear be themselves. One kind of "left" might be a radio button label, and the other might be a column header for a table.

[Leartin]

"Vehicle" can be more troublesome. I can't think of any word in Norwegian that covers vehicles on land, on water and in the air, that it would not be very unnatural to use. Translated into English, it would be closer to "mode of transport". The German cognate is "Verkehrsmittel", which does not appear to be used to translate "vehicle". Even a common word for rail and non-rail vehicles feel unnatural. However, I am not sure how natural it is to use the word "vehicle" for a ship in English.

"mode of transportation" is closer to waytypes then vehicles, vehicles would be the "means of transportation" Is the current Norwegian translation "Transportmiddel"? The German "Verkehrsmittel" includes other traffic related infrastructure (so pretty much everything the player can build in Simutrans is a "Verkehrsmittel"). You could say "Mobile Verkehrsmittel" to be specific, but not in everyday speech. (Not that "Verkehrsmittel" is something you'd say in everyday speech either)
English typically doesn't call a ship a vehicle, it's a vessel. Though a vessel is a water vehicle. It's a similar problem in German: Vehicles are called "Fahrzeug". A plane is a "Flugzeug". There is the technical term "Luftfahrzeug", which contains planes but makes one rather think of a Zeppelin, and someone would mention that a plane doesn't "fahren" (Fahr) but "fliegen" (Flug) hence can't be a Fahrzeug.
Early game starts have horses, which are neither vehicle nor Fahrzeug, but Transportmiddel

This is not a matter of translating the real-life word "vehicle", but creating jargon for the Simutrans game object. That is, taking an existing word and keeping it's essence, but redefining it for the specific Simutrans context.
Regularly, a factory is an industrial site at which goods are manufactured or processed. In Simutrans, a factory is anything that produces or consumes goods, and clearly distinct from "industry" which doesn't.
Regularly, a convoy is a bunch of vehicles travelling together as one unit. In Simutrans, a convoy is a bunch of "vehicles" travelling together as one unit. It's different since in real life, a train is one vehicle, while in Simutrans, a train consists of vehicles, train cars are vehicles. The best English word for a convoy in Simutrans, ironically, would be "train", as it can also be used for wagon trains, camel trains or road trains. In German, "Kolonne" could be a bit better. But nobody would change those translations, since convoi is Simutrans jargon.

In the end, what all this means is that for game objects, you don't need to translate the English word. The English word itself is an approximation of the object in question, a redefinition. Perhaps there is a Norwegian word for "something that moves", and while nobody would call a train "something that moves", it IS "something that moves" and seperates it from an immobile station building; it would work in the context of Simutrans.

[Leartin]

I just played around with the translator and got something to work (but sadly, I can't seem to be able to update the repo, so I can't exactly give a patch right now)
Basically:

Code: [Select]

const char *translator::lang_info::translate(const char *text) const
{
if(  text    == NULL  ) {
return "(null)";
}
if(  text[0] == '\0'  ) {
return text;
}
return texts.get(text);
}The actual translation thingy returns NULL if it doesn't translate, rather than the untranslated string, to enable retrying.

Code: [Select]

const char *translator::translate(const char *str)
{
const char *trans = get_lang()->translate(str);
const char *substr = str;
while (trans == NULL){
substr = strstr(substr, "|");
if (substr == NULL) {
return translator::translate(str, get_language("en"));
}
substr++;
trans = get_lang()->translate(substr);
}
return trans;
}


const char *translator::translate(const char *str, int lang)
{
const char *trans = langs[lang].translate(str);
const char *substr = str;
while (trans == NULL){
substr = strstr(substr, "|");
if (substr == NULL) {
return str;
}
substr++;
trans = langs[lang].translate(substr);
}
return trans;
}When you try to translate stuff and don't get a translation back, this tries again with a reduced string (for now: anything after the first | ) If there is no string left to try, it asks for an English translation with the same procedure. Pipe is just a placeholder, as any string could be used as seperator.

[Vladki]

If something like this goes into production, it would be nice the have fallback language configurable too. Some people may prefer fallback to German or any other language.

[Leartin]

If something like this goes into production, it would be nice the have fallback language configurable too. Some people may prefer fallback to German or any other language.

The last fallback language needs to be English, as the intention is to hide the raw strings from players. As prissi pointed out:

The problem is also that most languages will not show a translated key for a long time. Hence better have something which is meaningfull in English at least.

Always using English as Fallback means that the raw string does not need to be meaningful for players anymore, only for translators, since an English translation for players can be expected.

That being said, the hardest part about adding configurable fallback languages would be the language dialog.

[Ters]

"mode of transportation" is closer to waytypes then vehicles, vehicles would be the "means of transportation"

I just got "mode of transportation" from the interwikis between Wikipedias.

Is the current Norwegian translation "Transportmiddel"? The German "Verkehrsmittel" includes other traffic related infrastructure (so pretty much everything the player can build in Simutrans is a "Verkehrsmittel"). You could say "Mobile Verkehrsmittel" to be specific, but not in everyday speech. (Not that "Verkehrsmittel" is something you'd say in everyday speech either)
English typically doesn't call a ship a vehicle, it's a vessel. Though a vessel is a water vehicle. It's a similar problem in German: Vehicles are called "Fahrzeug". A plane is a "Flugzeug". There is the technical term "Luftfahrzeug", which contains planes but makes one rather think of a Zeppelin, and someone would mention that a plane doesn't "fahren" (Fahr) but "fliegen" (Flug) hence can't be a Fahrzeug.
Early game starts have horses, which are neither vehicle nor Fahrzeug, but Transportmiddel

"Transportmiddel" is also a word that is a bit unnatural to use. It also more a translation for convoi_t, than vehicle_t.

I also got the impression from Wikipedia that ships are watercraft that are vehicles. That Schiff are Wasserfahrzeug, and that has Fahrzeug in it right away. Airplanes has a rather convoluted route to vehicle, but it is there. While Flugzeug goes right to Luftfahrzeug. In Norwegian "fartøy", which has the same etymology as "Fahrzeug", primarily makes one think of watercraft, but it can also be used for aircraft and spacecraft, especially with corresponding prefixes. That makes it quite similar to the English "craft". Land vehicles, ranging from bicycles to trucks, would be "kjøretøy", where "[å] kjøre" basically means [to] drive. (Drive in the sense of driving a car, not a cattle drive. Another example where one word in English has to different translations. The other one in turn can be translated to three different English words in a different context.) I believe even horses count as "kjøretøy", as they were (along with oxen, I guess) the original alternative to pedestrians. Although I don't think the verb "kjøre" becomes natural unless the horse is pulling something.

So I guess the point is: things are complicated.

As for fallbacks, the system I am used to, in Java, has a rather simple fallback system. Translations (and other localizable resources) are lookup up based on language, country and variant. I think it first drops the variant, then the country, and finally everything. That means that the ultimate fallback formally has no language. It is called the root locale. If a translations doesn't even exist there, an exception is thrown. When I use it, I therefore put the most complete translations in the root.

[Vladki]

If I understand correctly, both English and German distinguish between land, water and air "vehicles". Same in Czech: vozidlo, plavidlo, letadlo. The generic term is "dopravní prostředek", but it sounds too formal. The important difference is that the meaning in game is different from real world. An articulated tram in game consists of several vehicles while in real world it is considered one. So whatever we use to translate vehicle and convoy (train) will never be  a perfect fit.

[ampersand]

I think I might have one example of reusing strings. In the convoy details windows, a message may be read:
16 bags mail (pak dependent)
It's obvious that a better form in this case would be
16 bags of mail
However in the Goods list there is a table with all types of cargo, where also the same string mail is used. So some languages require different strings in these two cases, whereas some may use the same one.

It may be beyond the scope of this thread, but I have noticed an issue of higher level than "repeating vs individual".

In the above example the syntax pattern in the convoy dialogue is:
$number $unit_name $freight_type
It reflects affirmative syntax of many languages, ex. I have found 2 pieces of cake. But one can imagine a language (I don't know any such myself) where the most correct syntax would be Cake pieces 2 I have found. May be there is a way to solve such differences with appropriate programming, but I have no idea of such solution. Therefore I like to use another one whenever I am involved in data presentation localisation. And I consider Simutrans a very data-oriented managerial game.
The solution rejects natural language phrases simulation:
The train has delivered 16 bags of mail to Heathrow station
in favour of tabular data presentation:
Arrival: Heathrow station, mail, 16 bags
which doesn't aspire to adapt to all the possible languages but to be a precise statement of any kind of data that may be structured.
This is not an actual proposal of any kind. But if any day a major refactoring of game messages were considered, I would vote in favour of tabular syntax.

All in all, I am in favour of  individual strings, as its more flexible in introducing new languages successively.

[Vladki]

So some languages require different strings in these two cases, whereas some may use the same one.

Exactly!  Czech is one of those. It is in many places. Like production: X crates of stuff per month...  Generally I think there are more places where 'of' should be used than not.

[prissi]

But in these case the translation should maybe no bags, but bags of.

This is just a further case of not to reuse. But the ship has sailed long ago: No one will rewrite Simutrans now with this in mind, and we have not enough translators to replace everything. In principle you can write a script that creates all the complete string and changes the program. But then there are already translated string and almost nobody will go through it.

So the consent for future extensions seems: Avoid reuse unless it is clearly the same context.

[Vladki]

But in these case the translation should maybe no bags, but bags of.

I disagree.    The form of the word "bags" will not change (at least in czech & slovak and other slavic languages) if you say just "X bags" or "X bags of stuff".
But the form of "stuff" varies if it used as: "This factory produces stuff." V.s. "This factory produces X bags of stuff per month." So the translation is clearly "stuff" vs. "of stuff"
Of course the form of "bags" varies with the value of X, but that's entirely different beast.

I agree that rewriting the whole game and splitting such uses is not a priority (or even feasible). And most of the uses in game should be "of stuff" as it relates to production rates, or storage/transport capacities.

[ampersand]

Does it all lead to a conclusion that
If the game was started with strings structure well adapted for German
with every new language a new need for another pack of individual strings arises...
?