Translators do not translate pieces of text, they translate meanings of pieces of text. For small projects and long text snippets this does not make much of a difference. A human translator can figure out the meaning and come up with a translation for it. Drupal now uses 190.000 unique strings and some of them are used in many places and by many different modules. While it is nice to reuse already translated strings in different places of the user interface some of them have a different meaning albeit having the same text.
This ambiguity is a big problem for the translation of Drupal. This is aggravated by the fact that the English language is quite simple and many languages use different expressions for things that have the same text in English. A simple real-life example is the string "view" that can either mean "show"/"display" or a view as provided by the views module which translates to something different in most languages. There are many more examples, probably more than most natively English-speaking Drupal developers are aware of.
There are two solutions to this problem: A) using IDs as source strings instead of English language used in the interface and B) providing additional information for ambiguous source strings to reflect the context the string is used in.
A) could lead to some overhead in order to avoid ID collisions and still be able to share translations across different modules. Also even English-only sites would need to use the local module and there would not be a guaranteed fallback for missing translations anymore. I think this solution is viable (many projects use it) but is not as straightforward as it may seem.
B) has not been possible for a long time but with Drupal 7 the t() function has been extended by a new parameter allowing the use of context information. The (awesome!) Localization Server already supports contexts, too. So I think from the infrastructure side of things we are ready to go. But I have a few questions I would like to discuss:
- Can contexts be used to disambiguate single strings or are they only suitable to define a few general contexts?
- How can we educate developers to use contexts in a way translators can benefit from?
- How can we provide a feedback channel from translators to developers to indicate the need for a new context?
What do you think? Are contexts the solution to ambiguity issues?
Comments
What may contexts mean?
Contexts may be similar to free tagging: you can but nothing and everything into it. Unless you don't have a predefined set of contexts, they are useless. If you have a set of predefined contexts they may be too limited to the developers.
I better like to give every string a unique ID and join the translations to this ID. The ID may consist of
Thus we gain the following advantages:
The disadvantages are:
And if the module developer could also add contexts or comments to the string, this would be very useful at all!
I would also like to introduce a default language code "Drupal" instead of "English". "English" would then be handled as any other language. Possibly English translators would use other terms to present to the audience than the developer of the module decided to use. Thus we would get a great user experience for native English speaking users, too.
..........
Wilfried
Drupal: a CMS without typo in its name
Unique ID approach not straightforward
When you write about "unique IDs" do you refer to the original t() string or to contexts? Either way there are some problems with the unique ID approach. By making every string unique to the localization system you immediately lose all translations in all languages for all strings used more than once across all Drupal modules. Invalidating these strings would mean a lot of unnecessary extra work.
Reusing strings is a good thing more often than not. Think of the string "Access denied" that is used in many modules. You could write a converter that inserts the same ID for identical strings but that would break your naming convention and that does not solve the problem for new strings. An advantage of the unique ID approach is that module developers have their own string namespace and do not risk having unsuitable translations from different modules.
What happens if a module's name changes? If the IDs change along with the name all translated strings in all languages become invalid. And if the module name part of IDs can not be changed once you define them, you cannot resolve name conflicts between modules anymore. Module names do not change often but this does not look like a clean approach. I would rather suggest a central registry for module IDs. Thus we could use a short code for every module (I am thinking more integer here rather than a string).
I don't think your other points are too relevant. The information of the modules a string occurs in is available in the localization server as well as in external editors like poEdit as it is right now. There are already workarounds for English users to change strings (string mapping in the configuration or installing an English "translation"). I don't see a difference to the current situation concerning scanning for unused strings. I don't think we need a "Drupal" language but I let the English users decide on that :-).
Need feedback
I would like to present you my idea about the use of contexts. Maybe contexts are not the right tool for disambiguating individual strings (or are they? Discuss) but there is no doubt contexts can be used to help translators. A lot. I suggest the introduction of (at least) 3 contexts:
The reason I would like to discuss this is that I feel there should be some kind consensus before suggesting changes to code in the issue queues of virtually every module there is. Making these small changes as soon as possible can save some work for the translators as many translation teams will intensify their work as the release date for Drupal 7 gets nearer and nearer. So please share your thoughts on this subject. Thank you.
IMO general contexts are not
IMO general contexts are not enough. They are useful in many cases, but far too general to be of any help in others. For instance, think about the "May" problem (The full month name vs. the short name, which in English are the same but have to be translated differently). They solved this with a "hack", adding some parameter indicating which one it is. The point here is that there are some situations in which a single string has to be translated to different translations depending on their context. And this context has to be kind of meaningful to the translator. More like free tagging, i guess.
As in the previous example, the word "View" could be translated into Spanish as "Ver" if it is considered a verb, or into "Vista" if it's considered a noun. Translators have to be able to know which one it is from the context. In this case, the context could be something as simple as "verb" or "noun". Or something more complex, like "views-module-permission" and "views-module-page-heading-section" (or whatever). This could happen to any string, not just module names, and a string may have different meanings even inside the same module, so having a generic context "module-name", or even a context for each module (e.g "views" or "ckk" or "node") won't be enough.
BTW this last example leads me to think It would be nice if the translator could be somehow pointed by the context to the place in which the string is used, to be able to see it "in-place".
Drupal issue
FYI guidelines for context are being discussed in https://drupal.org/node/1035716 currently (titled Decide and document guidelines for using string context)