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.In the current drupal translation system (similar to Wordpress), translations are keyed by string.
This has the following problems:
- Possibility of nameclashes, if the same string is used in different contexts.
- The information gets lost if only one letter in the string is changed.
- It is not supposed that you change the english version of the string for your own site. (you can use string_overrides module, but that's against the nature of the translation system.)
I would like to kick off some brainstorming about an alternative system:
- Translated strings are indexed by keyword, and namespaced by module or theme, and an optional context keyword to allow context-specific overrides.
- Implement hook_strings to define additional information about strings used in your module, and default translations.
- In your sourcecode (mostly in theme / template functions) you will usually only have keyword arguments, but you can add default translation arguments to avoid empty strings in your output.
The new system could be used in parallel with the old system (anything else would be a suicide mission). It can even come as a contrib module - but still I would like to see some brainstorming first. Maybe I missed something about the existing translation system.
Some demo code:
<?php
function theme_something() {
// get a translation engine instance that already knows the module name
$t = get_translation_engine('modulename');
$html = $t->t('keyword');
}
?>| Comment | File | Size | Author |
|---|---|---|---|
| #1 | keyword_strings.zip | 4.38 KB | donquixote |
Comments
Comment #1
donquixote CreditAttribution: donquixote commentedThis module has been in use on one of my sites for quite a while now, as a translation system for some custom modules.
The admin interface is horrible, and overall I did not invest any more effort than necessary for my own needs.
However, it could give some inspiration.
Seeing posts like those below, I think a new approach for translation of user-defined strings is very much needed.
Gábor Hojtsy
String translation: why using t() for user specified text is evil?
i18nstrings.module
Translating user defined strings
Duh! How odd.
Comment #2
donquixote CreditAttribution: donquixote commentedOpen ends:
- In addition to keywords, there can be a combination of keyword and entity ids (such node nid, field id, etc) as primary key.
- Text can exist in different formats, and it can be rendered in different context (link title attribute vs plaintext email vs full html), with different filtering.
- Maybe we want to translate/localize other data, not just text.
- Default strings could be defined in yaml files (if not .po)
- Fallback rules for similar languages
- Fallback rules for variations of the same string.
- Fallback rules depending on user preferences (language cascade with priorities)
- Inline translation/authoring links depending on permissions.
- Editing the strings from different places: Module settings forms, node edit forms, translation interface, etc.
Comment #3
gagarine CreditAttribution: gagarine commentedWhat is the status of this issues? It will not append in D8 for sure... but is somethings we can see happens in D9?
Comment #4
gagarine CreditAttribution: gagarine commentedComment #5
catchThis is a big undertaking, so moving to the ideas queue.
Comment #6
yoroy CreditAttribution: yoroy commentedComment #7
PasqualleThis is a long overdue feature request.
Maybe an execution plan would help to move this forward.
My first suggestion is to divide the task into smaller child issues:
- lets create a proof of concept with messages
- module help texts
- umami demo content
- form labels, descriptions, placeholders
- ...
- deprecate the t() function
Also need to agree on the translation file format. I would suggest a json file, as it is more common these days.
Comment #8
PasqualleIssue #2923431: Refactor translation system to use IDs instead of strings marked as duplicate. Contains some implementation ideas.
Comment #9
DieterHolvoet CreditAttribution: DieterHolvoet at Minsky commentedYesterday I started work on a simple module integrating the Symfony Translation component, which allows using keys instead of English strings. Maybe this could be the way forward, instead of trying to roll our own solution? The project has some open issues with things that need implementing, but the current development version already has all basic functionality working.
Comment #10
solideogloria CreditAttribution: solideogloria commentedFrom reading the information about @DieterHolvoet's module linked above, I think it sounds like a great proof-of-concept. I was wondering if this issue was going to need to be divided into two because there was discussion both about keyed messages and about translations. I think they are still two different things, but if translation supports both methods as shown in the module, I think backwards compatibility would be doable, making it easy to deprecate the t() function. It also gives two options for usage, which could make it easier for people to adopt and adapt to.