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
Postponed: needs info
9.5
(Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.