Good morning, folks
I help to translate Drupal into Spanish. Many times I find an issue I don't know how to solve due to the current design of this —otherwise excellent— localization server. It is the trouble with homonyms.
It's not just a question of "this is a verb and this is a noun", but "this translates as x and y" and both x and y are meanings wholly and absolutely different. That is: Either meaning you choose, there will be many translations where the result will be absurd or incomprehensible.
An example: Order -> 'Orden' in Spanish is used for 'command' 'orden' (as in software usage or army drills), for commercial issues 'pedido' (something you want to buy) or... 'method of sorting something'.
Then translating 'Save order' cannot mean both 'Guardar pedido' ('save commercial paper' -> commercial meaning) AND 'guardar orden' ('save sorting method').
Somewhere in the near future... any method to solve or overcome this?
I do not think that a contextual function approach (noun / adjective / ...) can be a solution as it is a matter of contextual semantics, I believe.
Thank you
Gustavo (from Madrid)
Comments
Comment #1
gábor hojtsyDrupal 7 supports free form contexts. So *developers* can (and should) specify contexts for short strings or any string for that matter which can appear in multiple contexts with different meanings. Drupal 7 core itself only defines the "long month name" context (as you can see on localize.drupal.org), and we expect contributed modules to define contexts for other strings. We do not have a set of suggested contexts or so and translators might be of great use to make suggestions there. It would be great to have some structure and consistency.
I took the liberty to retitle this issue for that (and currently assume we need this issue somewhere else, but its a cross-issue for all of contrib, so no good idea where to put it :)
Comment #2
Anonymous (not verified) commentedMh... not being a developer myself... I don't think it's an easy issue to address (either in Drupal itself or in contributed modules).
But, as I said I rather doubt that the 'functional' approach (I'm a verb, I'm a noun...) would suffice to solve it. Seems to be more a thing of the string 'saying' something like 'as in...'. that is: 'Order (as in commerce)' and 'Order (as in commad).' It's all about meaning, really.
Tricky, anyway
Thanks
Gustavo
Comment #3
gábor hojtsyYes, right. That is why Drupal core allows for free form context definitions, so module developers can say "May" as in "long month name", so the "long month name" context will appear in .po files, the source code of the module as well as on the UI of l10n_server. Since only developers can tell us which context they use certain strings in, we need them to dress their code up with use of these contexts.
Comment #4
droplet commentedsimilar issue #619376: Support multiple translations of the same strings
I'm looking and waiting for a best practices. if we can do something on Local server maybe more better. Sometimes, a string would exist in 10 modules that not easy to inform 10 maintainers to update it. and we should wait for a long time to update it. (and they may reject).
btw, contexts maybe the only way that really solve the problem.
I do not familiar with Context. if a single strings have 10 more meaning in 30 languages, should it defining contexts 10 times ??
Comment #5
gábor hojtsyWhatever we do on the server side we are limited by the options provided by Drupal, where the translations will be deployed. Since Drupal only supports contexts in Drupal 7 and that even requires module maintainers to be aware and specify those contexts, the answer is to submit issues and get contexts into modules. Module maintainers will only be aware of these possibilities once faced with the need for them. The same way they need to be aware of the t() and related localization APIs, we need to educate them which strings needs contexts. They'll not be able to tell in most cases, but we can't get translations using contexts out without them cooperating. Clear?
Comment #6
droplet commented@Gábor
thanks :)
Comment #7
Anonymous (not verified) commentedExcuse me, Gabor if I reopen this issue with a question
Let's suppose an imaginary case: This is a Dutch programming team that speaks English. They design and build a module on worm-breeding (or whatever).
In this Drupal way of life, where contexts are to be given by programmers, how would they know the umpteen possible contexts of all the main terms and phrases of their own module?
I mean, if "worm" means in language A (Spanish, Klingon or whatever...) "command / breed / compost", how would this team know about this to provide context?
If I have understood this all right, the answer is "they have to be informed about this by the people related with this issue in language A", then...
Isn't this a case similar to mixing content with style? (but much more intense). Coding and comunicating with the users are as different as content and style, I believe.
Not that I have a solution or idea, but wouldn't it be better to think of a way to move this effort away from the module maintainers to the translation maintainers? Somehow this line was started with the localization server. Wouldn't it be a good idea to use it for this... er... somehow?
Take this just as it is, please: A sheer head-scratching thought.
Gustavo
Comment #8
gábor hojtsy@gusgsm1: all module developers do is to use stuff like t('breed'). When Drupal / PHP runs this, all it sees that developers wanted to translate 'breed' to some language. Now if you are a translator and know 'breed' needs a different translation based on different circumstances, you could say 'breed' is translated 'A' if X and translated 'B' if Y. You could then hand this over to Drupal. But Drupal does not know whether it is X or Y when the code is run. For that to work, the code actually needs to specify X or Y, as in t('breed', 'as in X'), so Drupal knows it needs to take that version of the string. Without the code informing Drupal about the context, it cannot make up a context.
How do you imagine us being able to specify contexts with translation and then telling Drupal about all the different variants without giving Drupal any guidance as to which variant to use in which case?
FYI actual syntax for contexts is
t('breed', array(), array('context' => 'X'));Comment #9
Anonymous (not verified) commentedWhat about some mechanism inside the server that could store and serve a "semantic" exception?
Let's say:
In all the modules X translates as Y, but... a module marked with a "exception" (outside the module, not inside):
(In this module) X = always Z.
So that the server serves Y (ahem...) in every module using X but in this one, where it serves Z. That is, something retrievable from the translation side of the server (a simple text file?).
Or...
Some way to mark "this module has exceptions" and then serve them as such...
I know that this (if doable) could yield way to an undesirable casuistic development.
In the end is doing once inside the server what the final user (the site administrator) will have to do any individual time he installs a module (that is: Changing translations by hand to fine tune them).
Excuse my naivety anyway
Comment #10
gábor hojtsy@gusgsm1: drupal does not know the module the module it displayed t('breed') from. It knows the first page it was displayed at in some cases (eg. it knows 'it was displayed on node/13 first'). This does not tell Drupal anything about whether it came from CCK or Mollom or Pathauto. Drupal does not know where the t() call is coming from, all it knows is the arguments passed via the t() call.
Comment #11
gábor hojtsyThis is being discussed in #1035716: [policy, no patch] Decide and document guidelines for using string context.