Task #100031
closed
Inconsistency of naming transOrigDiffSourceField fields (l18n_diffsource should be i18n and l10n_diffsource)
0%
Description
- AFAIK l18n (with an L as in Localization) is not the convention , it is i18n (with an I as in Internationalization)
- why use both?
- shouldn't i18n_diffsource (i18n for Internationalization) be more appropriate (see source below)?
The following field names are currently used for transOrigDiffSourceField:
sys_file_metadata.php: => 'l10n_diffsource', sys_category.php: => 'l10n_diffsource', sys_file_reference.php: => 'l10n_diffsource', pages.php: => 'l10n_diffsource', sys_file_collection.php: => 'l10n_diffsource', tt_content.php: => 'l18n_diffsource',
Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale). Localization is sometimes written in English as l10n , where 10 is the number of letters in the English word between l and n.
Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language. Internationalization is often written in English as i18n , where 18 is the number of letters between i and n in the English word.
Updated by Eric Harrer 9 months ago
Considering the context, we can state that the process taking place here is translation and not localization (concerning the region) or internationalization (concerning the culture). The name "t9n" would accordingly be the most correct notation. Since we already use "l10n" (localization) for other fields, this name would also be conceivable. I would exclude "i18n" in any case.
Updated by Eric Harrer 9 months ago
- Related to Epic #101557: Translation Handling Findings added
Updated by Christian Kuhn 6 months ago
- Status changed from New to Closed
Hey.
I guess we all agree this is indeed an issue: The core tends to mix up l10n vs. l18n vs. i18n at various places, especially in database columns, for instance in pages and tt_content. This is from historic times where we did not know better, I suppose.
The good thing is, we have the TCA ctrl section to define the according column names.
I understand this mix is ugly and may be confusing to people.
However, it is not an important issue to fix: This is just a name in the database, even if wrong. Fixing this would be nice, but it wouldn't add much value to the product, it does not hurt that much, and thus has a rather low priority to work on.
The problem is that changing these field names to something better requires quite some effort: At least a migration wizard, the patches will have to deal with tons and tons of fixture files, and changing the columns names is also risky and potentially breaking for extensions that hard coded the names.
For this reason I'm going to close this issue as "won't fix" for now: If anyone wants to pick this up and actively work on it, we can of course deal with that in a fresh issue, or re-open here. But I think we should get this closed until someone feels the urge to actively adapt the code to see where it leads.