views:

109

answers:

2

In Drupal, strings that are shown to the user are supposed to be passed through the t() function like so:

$heading = "<h2>" . t("Product") . "</h2>";

This allows Drupal to translate the string into the appropriate language.

However, what if the same English word is used in two different senses on the same site? If I wrote a price calculation module that had a "Product" option indicating that discounts should be multiplied together, how could the localisation process know whether to translate the word as an item to be bought or an arithmetical operation?

Should I just avoid homonyms altogether?

+1  A: 

The simplest thing would be to use another term for one of the cases. A thesaurus is your friend here. How about "result" for the multiplication case?

Truth is, the t() function, and other similar functions in other languages like _() in GNU C internationalization (I forgot the exact lib name), was not designed to work well for words, but phrases, such as messages in dialog boxes. Maybe if you included the <h2>...</h2> tags in the translated string to disambiguate these cases?

Mike D.
+5  A: 

Very nice question (+1). There was some discussion on one of the Drupal mailing lists back in 2006, I believe. The core devs fiercely defended the current design of the i18n and l10n infrastructure. The problem of homonyms for Indoeuropean languages is limited, but when you move for example to China, that becomes overwhelming as each ideogram in Chinese represent a bunch of very different concepts, and you can get the intended one only by looking at the context.

Although there is not a coded solution for homonyms, there is a very simple best practice: provide context! Whenever possible feed the t() function with sentences, not single words, or to say it with the code documentation in common.inc:

When using t(), try to put entire sentences and strings in one t() call. This makes it easier for translators, as it provides context as to what each word refers to.

When this is not possible, and using a synonym with a different spelling is not an option, you could embed transparent HTML tags providing context for translation. For example:

$heading = "<h2>" . t("<span id="product-as-in-stores">Product</span>") . "</h2>";

This way you provide essential information to translators, while if you had simply embedded the <h2> tags, the translator would have to guess what product refers to.

This is - BTW - one of the very few cases where embedding HTML tags in t() strings is not considered bad.

HTH!

mac
I wish t() accepted an optional default translation argument like t("Product as in stores", "Product") so your transparent tag workaround wasn't necessary. Thanks for your help.
ctford
That is actually a neat idea that could be elaborated further. I will think about it and see if I come up with something decent enough to be proposed for Drupal 8 (Drupal 7 API's are already forzen). Thanks! (+1)
mac
Very clever using "transparent" html. I know a few themers, however, who would freak if they saw such a thing. Still it's the best solution I've seen yet (+1)
googletorp