Talk:Localisation guidelines

CLOSED This issue is closed

Rules look clear enough for most

The most important rule seems to be a rule about translation for interpreters. And it si logic. Messages should be translated. On the other hand it is quite difficult for us to translate from English to Czech. Czech language is fusional, English is analytic. Translation between analytic languages is pretty simple, but not translation from an analytical language to fussional. E.g. Czech has 7 cases and uses them for sever types of words. That makes us trouble at the time we dont know the context of the message (simple message "Left" could be translated via 6 different times - thats why context help is appriciated.

Even more trouble comes with variables. The use of some variables does not allow to translate the message corectly. In those cases its better to compose, that translate. Do you think it would be possible in such cases?

What do you mean "compose"? If you are talking of Localisation guidelines, they say "translate, don't customise". "Customise" is used in the meaning of local customisations.

It is rather difficult to find a way to track in eahc message the correct grammatical case to use, because even languages that have cases don't always use them the same way (there are even languages opposing grammatical case differences by changing to another plural form of another case in some situations...) Unless you really know the target language (here Czech, or Russian, or German) a programmer cannot guess which case to specificy when using substitution variables. So you may even create translations with multiple alternatives for those variable contents, it is not sure that the main message could use the GRAMMAR construct to specify the appropriate case to select for the replaced term.

This is a problem not so easy to solve, but there are some hints about it in another translation interface than translatewiki.net:

Have a look for example at the translation interface designed and used by Facebook (for its own use, but also for use by its hosted applications made by third parties).

• It allows multiplying the number of forms for a single source translation unit, and then mark each one with distinct conceptual *qualifiers* about how which form must be used in sepcific contexts; then a composite message will be able to select automatically the correct form according to the presence of the qualifier in the translation of the composite translation unit using these variables. Some qualifiers can be plural, gender, case, or selectors for different people (the reader himself, the subject of the sentence, the object of the sentence).
• Each language has a set of known qualifiers which can be selected for creating multiple variants of the same message, but some source translations may define their own qualifiers that translators may, or may not use.
• There are also some additional complexities because there are also fallback rules between variants (those fallback rules being also language-dependant !). But Facebok does not expose these rules that are either hardcoded, or designed by a restricted set of persons which are allowed to create custom code for functional hooks, that must remain stable as they can affect a lot of translations (this is the same restriction as if someone wanted to change the plural rules for a specific language here in translatewiki.net: their relative order and the way they fallback from one variant to the other is also language-dependant).