Some general questions about translations

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Post Reply
User avatar
DarkFenX
Engineer
Engineer
Posts: 98
Joined: 16 Oct 2006 20:32
Location: Russia, Saint-Petersburg
Contact:

Some general questions about translations

Post by DarkFenX »

Since we have lots of things that are absent in english, we face some issues too often. Example of it - gender... In cyrillic languages (at least) we have more than 1 gender, and all adjectives are tied to the gender of the nouns. For original 'translation' it's enough to write none/low/medium/high string, while in russian it's wrong. We may workaround this in 2 ways:
1) Distort original string a bit (which describes option) to bring all nouns together to 1 'predefined' gender (i prefer this way, but some people still disagree with it).
2) We have 'general' words too. They may be used (and it's present way of translation), but ugly too anyway (really unpleasant to read line with it :) )
So, i suggest to split all that strings used more than once to avoid such linguistic problems. It may be done in trunk, not in forthcoming 0.5, or when adding new strings they can keep their old value to not bother other translators...

Edit: sorry, i hadn't knew that ottd supports genders (only about plural). That's because of old habit to modify .txt file manually, then commit changes... will look thru it :)

So, another question :) why options menu is so inconsistent? Just as an example - american english selection. In UK english it's called 'American', in american - 'English (US)', etc.
Also, maybe whole language menu should use english (icluding its title, and maybe excluding currently selected language which may be localized) - it may be hard for user to find his native language if he had selected catalan or dutch and he doesn't know them.

One more 'suggestion' - menu sorting. Townname selection menu, for example, is well-sorted in english. In russian sorting is at learst irrational :)
Last edited by DarkFenX on 17 Jan 2007 15:09, edited 1 time in total.
- It's hot as hell in here.
- You see it too? For me, it's always like this.
-------------------
ICQ: 302028069
Jabber: DarkFenX@jabber.org
User avatar
miham
Engineer
Engineer
Posts: 20
Joined: 02 Jan 2004 16:38
Location: Hungary, Érd

Re: Gender of adjective

Post by miham »

DarkFenX wrote:Since we have lots of things that are absent in english, we face some issues too often. Example of it - gender... In cyrillic languages (at least) we have more than 1 gender, and all adjectives are tied to the gender of the nouns.
[....]
For more information on capabilities, please read this docs: http://wiki.openttd.org/index.php/FormatOfLangfiles

Cheers,
Miham.
EOF
Quark
Transport Coordinator
Transport Coordinator
Posts: 325
Joined: 20 Sep 2006 11:36
Location: Russia, Moscow

Post by Quark »

fisrt post updated — new question: how to implement proper sorting in lists?
Image
Quark
Transport Coordinator
Transport Coordinator
Posts: 325
Joined: 20 Sep 2006 11:36
Location: Russia, Moscow

Re: Gender of adjective

Post by Quark »

DarkFenX wrote:So, another question :) why options menu is so inconsistent? Just as an example - american english selection. In UK english it's called 'American', in american - 'English (US)', etc.
Also, maybe whole language menu should use english (icluding its title, and maybe excluding currently selected language which may be localized) - it may be hard for user to find his native language if he had selected catalan or dutch and he doesn't know them.
IMHO, every language must be spelled in it's native language, so every who know corresponding language can select it independent from know it current language or not (in english he must know only where to click to select their native language :) )
Image
User avatar
DarkFenX
Engineer
Engineer
Posts: 98
Joined: 16 Oct 2006 20:32
Location: Russia, Saint-Petersburg
Contact:

Post by DarkFenX »

I guess that if user has enough knowledge to find language selection list, he knows spelling of his native language in english ;)
- It's hot as hell in here.
- You see it too? For me, it's always like this.
-------------------
ICQ: 302028069
Jabber: DarkFenX@jabber.org
Quark
Transport Coordinator
Transport Coordinator
Posts: 325
Joined: 20 Sep 2006 11:36
Location: Russia, Moscow

Post by Quark »

DarkFenX wrote:I guess that if user has enough knowledge to find language selection list, he knows spelling of his native language in english ;)
Maybe someone just pointed him where to click on screenshot :) Or he just learn one word from english :) Surely, he can learn another one, just imho :)
Image
User avatar
miham
Engineer
Engineer
Posts: 20
Joined: 02 Jan 2004 16:38
Location: Hungary, Érd

Post by miham »

DarkFenX wrote:I guess that if user has enough knowledge to find language selection list, he knows spelling of his native language in english ;)
I don't think that the behaviour suggested by you would be useful at all, since in my opinion that would be a step backward from the current behaviour.
EOF
User avatar
miham
Engineer
Engineer
Posts: 20
Joined: 02 Jan 2004 16:38
Location: Hungary, Érd

Post by miham »

Quark wrote:fisrt post updated � new question: how to implement proper sorting in lists?
I have an idea about a possible easy solution about it, I've mentioned it in #openttd and (partially) discussed it with other developers, I'll inform you when there's a decision on it.

In a nutshell, my idea is the following:
each language should have 2 additional strings:
STR_CASE_SENSITIVE_ORDER :ABC[...]XYZabc[...]xyz

and STR_CASE_INSENSITIVE_ORDER :AaBbCc[...]XxYyZz

And the ordering would based upon these strings...

[Edit: STR_NORMAL_ORDER has been renamed to STR_CASE_SENSITIVE_ORDER.]

Cheers,
Miham.
Last edited by miham on 17 Jan 2007 19:17, edited 1 time in total.
EOF
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Post by DaleStan »

I understand CASE_INSENSITIVE_ORDER, but what purpose would the NORMAL_ORDER string serve?
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
User avatar
DarkFenX
Engineer
Engineer
Posts: 98
Joined: 16 Oct 2006 20:32
Location: Russia, Saint-Petersburg
Contact:

Post by DarkFenX »

I don't think that the behaviour suggested by you would be useful at all, since in my opinion that would be a step backward from the current behaviour.
But it's not so hard to have the same language names if languages are almost the same too, initially i suggested to standardize it in any way so we wouldn't have 'american' vs. 'english (US)'. Not a big deal, but annoying for me (don't know why though).
In a nutshell, my idea is the following:
each language should have 2 additional strings:
STR_NORMAL_ORDER :ABC[...]XYZabc[...]xyz

and STR_CASE_INSENSITIVE_ORDER :AaBbCc[...]XxYyZz

And the ordering would based upon these strings...
Simple, but effective :) great
- It's hot as hell in here.
- You see it too? For me, it's always like this.
-------------------
ICQ: 302028069
Jabber: DarkFenX@jabber.org
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Post by DaleStan »

miham wrote:[Edit: STR_NORMAL_ORDER has been renamed to STR_CASE_SENSITIVE_ORDER.]
I still don't understand. Why would you ever want the UI to be sorted case-sensitive? And if it's an internal sort, not for the UI, then one sort is just as good as any other, so you could just as well use the insensitive order, or whatever order strcmp happens to use.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
User avatar
DarkFenX
Engineer
Engineer
Posts: 98
Joined: 16 Oct 2006 20:32
Location: Russia, Saint-Petersburg
Contact:

Post by DarkFenX »

Well... i looked at gender implementation. But for translation i want a bit different thing...
Example:
---
##gender m f n p
...
STR_680D_INTELLIGENCE_OF_COMPETITORS :{LTBLUE}Интеллект конкурентов: {ORANGE}{G=m}{STRING}
STR_6812_QUANTITY_OF_SEA_LAKES :{LTBLUE}Процент покрытия территории водой: {ORANGE}{G=f}{STRING}
...
STR_681B_VERY_SLOW :очень медленн{G ый ая ое ые}
STR_681C_SLOW :медленн{G ый ая ое ые}
STR_681D_MEDIUM :средн{G ий яя ее ие}
STR_681E_FAST :быстр{G ый ая ое ые}
STR_681F_VERY_FAST :очень быстр{G ый ая ое ые}
---
As you can see - i've wrote 4 gender (male, female, neutral and plural 'gender') cases for each adjective. And i need to control gender when inserting adjective to another string (e.g. {ORANGE}{G=f}{STRING}). That's reverse case of existing system... dunno if it's possible, if yes, as far as i understand it requires a lots of changes in ottd itself.
Or maybe i should use cases instead?
-----------------------------------
About currency... in unicode we have following currency designations:
---
$ dollar
£ pound
¤ currency
¥ yen
₣ french franc
₤ lira
₧ peseta
₪ shequel
₫ dong
€ euro
---
Why won't we use them instead of 3-letter designations? I can change this in russian, but any other language will be 'missed'...
- It's hot as hell in here.
- You see it too? For me, it's always like this.
-------------------
ICQ: 302028069
Jabber: DarkFenX@jabber.org
User avatar
miham
Engineer
Engineer
Posts: 20
Joined: 02 Jan 2004 16:38
Location: Hungary, Érd

Post by miham »

DarkFenX wrote:Well... i looked at gender implementation. But for translation i want a bit different thing...
Example:
---
##gender m f n p
Currently plural shouldn't be a gender. since genders works different way and cannot be dinamically changed. I mean, if you are using a gendered string in a sentence you'll have to manually supply the gender of the string, which is not yet possible afaik. If I'm not mistaken, you need something like:
##gender m f n p
STR_FOOBAR: :{BLACK}{G={P m p}}{STRING}
I'll ask the developers whether it's possible to implement, but I'm quite sure that currently it's not supported.
DarkFenx wrote: As you can see - i've wrote 4 gender (male, female, neutral and plural 'gender') cases for each adjective. And i need to control gender when inserting adjective to another string (e.g. {ORANGE}{G=f}{STRING}). That's reverse case of existing system... dunno if it's possible, if yes, as far as i understand it requires a lots of changes in ottd itself.
Or maybe i should use cases instead?
Cases are for appending affixes to the nouns in variuos linguistic cases, such as accusative, possessive, etc...
DarkFenx wrote: About currency... in unicode we have following currency designations:
[...]
Why won't we use them instead of 3-letter designations? I can change this in russian, but any other language will be 'missed'...
Well, until it's the same in the other languages I shouldn't change them.
Maybe they looks like this because that's the official name of the currencies.
EOF
User avatar
DarkFenX
Engineer
Engineer
Posts: 98
Joined: 16 Oct 2006 20:32
Location: Russia, Saint-Petersburg
Contact:

Post by DarkFenX »

Maybe using 'plural gender' is wrong logically, but imo it's good way from technical point of view. As far as i understand, plural is used only when game tells us some parameter, gender - when we supply that parameter in string where gendered string should be inserted.
And it's much more convenient since we (=ru) have only one form of plural adjective for all genders (plural male = plural female = plural neutral), so "m f n p" scheme is convenient. And i don't think that "m f n mp fp np" scheme is worse than offered by you, it's still very convenient to use. The only drawback - in future it may cause some problems in very complex strings, which includes both plural supplied by game and gender supplied by translator:
"1 heavy passenger" "3 heavy passengers" "1 heavy crate of goods" "3 heavy crates of goods"
"1 тяжел(ый) пассажир()" "3 тяжел(ых) пассажир(а)" "1 тяжел(ая) короб(ка) товаров" "3 тяжел(ых) короб(ки) товаров"
1st is always adjective, 2nd - noun. While noun only depends upon plural (since namely it dictates gender), adjective have to listen both plural and gender parameters...

Code: Select all

##plural 6 <s p1 p2 p3>
##gender m f n
str_foo: тяжел{G {P ый ых ых ых} {P ая ых ых ых} {P ое ых ых ых}}
<str_foo: root{G {P ms mp1 mp2 mp3} {P fs fp1 fp2 fp3} {P ns np1 np2 np3}}>
Also, maybe it would be logical to supply different plural pragma for this case. In russian, for example, nouns use plural 6, while adjectives - plural 0 (like english). "Plural 6" is more general case, so it may be used for more specific case "plural 0". But i'm not sure about other languages, maybe they have 'incompatible' versions of plural for different parts of speech and can't find 'the most general' plural to use with all of them. If it's okay with it, i don't mind

Code: Select all

##plural2 0 <s p>
##gender m f n
str_foo: тяжел{G {P ый ых} {P ая ых} {P ое ых}}
<str_foo: root{G {P ms mp} {P fs fp} {P ns np}}>
Since in russian it may be simplified further (plural male = plural female = plural neutral)...

Code: Select all

##plural2 0 <s p>
##gender m f n
str_foo: тяжел{P {G ый ая ое} ых}}
<str_foo: root{P {G m f n} p}}>
str_foo2: {COMMA} {G=m}{str_foo} пассажир{P "" а а ов}
or w/o adjective-specific plural

Code: Select all

##plural 6 <s p1 p2 p3>
##gender m f n
str_foo: тяжел{P {G ый ая ое} ых ых ых}}
<str_foo: root{P {G m f n} p1 p2 p3}}>
str_foo2: {COMMA} {G=m}{str_foo} пассажир{P "" а а ов}
If one of the last 2 variants would be implemented (when G is wrapped in P) - perfect :) more perfect if we'll have possibility to wrap P in G too though :)
- It's hot as hell in here.
- You see it too? For me, it's always like this.
-------------------
ICQ: 302028069
Jabber: DarkFenX@jabber.org
ddream
Engineer
Engineer
Posts: 68
Joined: 28 May 2006 09:21
Location: 52° 13' N 21° 2' E

Post by ddream »

In translation there should be possible to translate some of town names and make them possible to differ in sentences. For example London when Polish language is selected should be Londyn. In subsidiary news instead of normal forms Warszawa or Kraków, forms Warszawy, Krakowa would be grammatical correct. IIRC it is also affecting German translation.
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 20 guests