Is having different translations for specific parameter values doable?

[xlenstra]

The problem Currently we have quite a few translatable strings dealing with amounts. For example, Current leader is [civInfo] with [amount] Technologies discovered., +[amount] untradable copies, [amount] Nations, etc. All of these work fine when amounts != 1, but at least in English, 1 Technologies, 1 copies and 1 Nations don't sound great, at least compared to 1 Nation, etc.

Other languages, such as German, might have noun genders, such as der Arbeiter or die Fregatte. Translating these for uniques such as <for [baseUnitFilter] units> would then necessarily result in choosing either der or die, which would sound weird for words of the other gender. In cases like these it's also not an option to add der or die to the translation of Worker and Frigate respectively, as they should be in the accusativ form due to the for, making it für den Arbeiter if memory serves me well.

The proposed solution One way to solve both these problems, is to have specific translations for specific parameter values. For example, adding the line [1] Nations = [1] Nation to english.properties to translate that correctly? Similarly, the translation for [Worker] units = für [jeden Arbeiter] einheden (excuse my German) could solve the problem for these languages, be it at the cost of basically the entire benefit that translations parameters give.

At least one challenge at first glance seem to me to keep the translation during regeneration of the translation.

Is this a good solution to this problem, and would someone be willing to code it?

[yairm210]

Hm, this could be doable, add a section below that's clearly delimited, add direct translations in translation map, interesting Your would need to have right side not contain any square brackets since it's a direct "a to b" translation with no funny business going on

[Mape6]

Other languages, such as German, might have noun genders, such as der Arbeiter or die Fregatte. Translating these for uniques such as <for [baseUnitFilter] units> would then necessarily result in choosing either der or die, which would sound weird for words of the other gender. In cases like these it's also not an option to add der or die to the translation of Worker and Frigate respectively, as they should be in the accusativ form due to the for, making it für den Arbeiter if memory serves me well.

Your example <for [baseUnitFilter] units> is not a problem in German, because the "for" is always reffering to the last noun "units". So in german it will be translated to die [baseUnitFilter] Einheiten and it doesnt matter whats within the square brackets. But there are many other strings where unit(s) is not present.

Because of a missing solution for that I live with some strange sentences :-)

[SomeTroglodyte]

I'm not sure gender can be solved entirely this way. But it's definitely a good idea, if only for its simplicity. But I would suggest - use an unmistakable marker. Is [amount] a specific "amount" entity or still the parameter placeholder??? Ideas: ['specific'], ⁅specific⁆, ┌specific┐- maybe not having the square brackets on both sides makes tests easier. On the other hand, no markers means the lookup won't need to create a modified key string.

I seem to remember software that actually had limited grammar, so e.g. a INamed would have a gender attribute, then translation entries were allowed to be marked as female or male only, fallback meaning neutral. Not easy as well ("your female unit vanquished a male unit" -> now xlt this without limiting the translator in order of the elements)...

right side not contain any square brackets

... except those that stay a placeholder while another parameter is special-cased?

I would not modify much in the data structures: One "has exception entries" boolean maybe, set when reading in the file(s). If set, start replacing parameters by combinations (1 param: 1 alternate form to look up, 2 params: 3 alternates, 3 params: 7 and so forth, since we won't go beyond maybe 5 parameters that's still not too bad. Or make that boolean a bit mask which parameter replacements to try... Yeah, markers are good. I'd choose ['specific'] probably because reachable on normal keyboards, ⁅specific⁆ has the disadvantage of needing help to enter them (but as said some tests could perhaps be easier, the 'brackets match' one could stay as it is)...

[JackRainy]

adding the line [1] Nations = [1] Nation to english.properties

That's quite interesting idea, worth to try, however, it does not solve the genders problem here. Also, there is another complication about amounts: while in English there are only 2 forms: 1 nation, 2+ nations, in some languages (e.g. Ukrainian, Russian) there are different forms for different amounts: 1 нація, 2,3,4 нації, 5+ націй. Probably, we will need to define several lines like [1] Nations = [1] Nation , [2-4] Nations = [2-4] Nations, [5+] Nations , does it make sense?

[SomeTroglodyte]

several lines

With the model I had in mind, that would work out of the """box""" but tediously:

['1'] Nations = 1 нація
['2'] Nations = 2 нації
['3'] Nations = 2 нації
['4'] Nations = 2 нації
[amount] Nations = [amount] націй

... with easy extra code maybe ['1','2','3'] ...

[JackRainy]

Also, an idea about genders: what if use an additional braces as a placeholder for affected verbs and nouns. For example: [unit] is destroyed = [unit] {знищений|знищена|знищено} // has 3 genders [unit] is destroyed = [unit] est {détruit|détruite} // has 2 genders [unit] is destroyed = [unit] er ødelagt // has 1 gender or all of them are equal While the units will have their own flag Cannon = Пушка {2} or Cannon = le canon {1}.

[SomeTroglodyte]

idea about genders

Sounds good, if complex to implement. The numeric gender markers on the RuleSetObjects might be a bit unfriendly to translators, and definition and application in your model are too similar. Maybe definition: <F> | <M> - since it's cut off and stored separately we get a space to deal with: demand the translator is aware not to place one probably. And application: {знищений|F=знищена|M=знищено} ?? And we get support for more genders than 3, depending only on the checks we place on the syntax.

[J0anJosep]

I would like to explain how it is dealt with in other projects I have worked on and allow translators to provide good localisation. I know maybe it is too complicated for the project.

Granary[num] = [def=m]graner[num | 0:s | 1: | 2:s]    // Setting the gender of this string and its variants: 0 graners, 1 graner, 2 or more graners
Cathedral[num] = [def=f]catedral[num | 0:s | 1: | 2:s]    // Setting the gender of this string and its variants

The [number] [construction] is being built = [number + construction:def | 1m:El | 1f:La | 2m:Els | 2f:Les] [number | 1: | 2:number] [construction, number] s'est[number | 1:à | 2:an] construïnt.
// First, the determiner el/la/els/les is chosen depending on [number] and [construction]
// Then [construction, number] adds the name of the construction, possibly depending on the number of units being built: cathedral for 1 unit, cathedrals for more than one.

So we can have:

number=1, construction=Granary
(The granary is being built.)
El graner s'està construïnt.


number=5, construction=Granary
(The 5 granaries are being built.)
Els 5 graners s'estan construïnt.

number=1, construction=Cathedral
(The Cathedral is being built.)
La catedral s'està construïnt.

number=2, construction=Cathedral
(The 2 Cathedrals are being built.)
Les 2 catedrals s'estan construïnt.

Of course, once you identify a widely used particle (usually determiners) in other strings that need to be formatted, you can add a new string for easing translations:

The[number, string] = [number + string:def | 1m:El | 1f:La | 2m:Els | 2f:Les]
[insert: The, number, construction] [construction, number] s'est[number | 1:à | 2:an] construïnt.

[yairm210]

I think the definitive answer for this question is "no".