Because the same expression can be translated in a lot of different ways, Drupal 7 now supports nice and shiny translation contexts.
Based on the industrial standard GNU Gettext, those contexts will allow translation teams to make better translations, especially of the short strings that are so numerous in the Drupal code base. For example, it was not possible previously to translate differently the 'View' tab and a 'View' of the Views module.
In Drupal 6 and below, translation contexts were already hacked in one place, the long month names:
-
#: modules/locale/locale.module:0
-
msgid "!long-month-name June" -
msgstr ""
In Drupal 7, that '!long-month-name' is now a proper context:
-
#: /drupal-core/admin/settings/regional-settings
-
msgid "June" -
msgctxt "Long month name" -
msgstr ""
Translation contexts will prove to be a power tool, as soon as we use it consistently across the code base. At this time, most strings are in the default context. We need your help to add proper contexts to every string that needs them. Those include menu links, menu tabs, module names, etc. For each of those, Drupal core will need to define a convention that contributed modules can follow.
Combined with other recent changes, like the new Regional settings screen, translation context contributes to make Drupal 7, and its localized versions, even more awesome.

Sounds great! How do we help to add context? Should we open an issue for each string?
To take a couple of examples, "filter" and "view" are strings used in both core and contrib. When I translate, I need to know if I'm translating "to filter" or "a filter", "to view" or "a view". So, I can open issues identifying these as problems, but I don't know how to search the code to find out where or how the strings are used.
How can you be sure that translation contexts will prove to be a power tool as soon as used consistently?
this is an excellent share.!! looking forward to more such posts.. keep up the good work!! I really appreciate it!
Laisser une réponse