Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.We currently have various identifiers for a translatable UI string:
1. The source string itself is used as a key for the lookup.
2. If the source string has an optional context assigned, that is part of the key.
3. Source strings can be put into textgroups, which are also part of the lookup key making strings unique in textgroups. This was implemented to support arbitrary configuration translation but turned out to be a *very bad* idea and is being removed in #1188430: Rip out textgroup support from locale module.
4. Finally, there is a location field that is only used once as a key, when generating JS translation files (for strings used in JS).
Unfortunatelt the location information from 4 is used very inconsistently. It can be one of three things:
A) a file path to the file it was extracted from (for full blown .po file imports)
B) empty (probably most common) for localize.drupal.org sourced .po files
C) .js file name for strings coming from a JS file (this is similar to A but has a very special meaning)
D) a web path where the string was first identified
In practice, people might be interested in either of these to help their translation efforts. However, the inconsistent use of location information makes it pretty hard to rely on the value for location in any meaningful way. Breaking this discussion out of Jose's explanation at http://drupal.org/node/1188430#comment-4626010
Comments
Comment #1
Gábor HojtsyAdding UI language translation tag.
Comment #14
smustgrave CreditAttribution: smustgrave at Mobomo commentedWonder if this is still a valid task for D10?