A key limitation of the current locale implementation in core is that there is no way to mark translations as outdated.
With the node translation module, we have a system for marking translations as needing updating.
But with locale, there's no way to tell that a source string has changed, invalidating existing translations.
Proposed approach: roughly follow what's done in translation module. Introduce a new table to track translation status. When source strings are updated, mark existing translations with translate = 1.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | i18nstrings-translation-status.patch | 4.37 KB | nedjo |
Comments
Comment #1
nedjoHere's a patch. Approach:
1. Add a 'translate' field to locales_target
2. When an existing source string is changed, set locales_target.translate to 1 (needs updating).
3. When a set of translations is updated, set locales_target.translate to 0 (current).
I have done no display of these data. Doing so would require extensive reworking of the core UI, which doesn't lend itself to modification (presents results in a table that can't be modified).
Instead, I think our best approach will be to rely on views. Views support for locale is being developed in #356276: Expose locale data to views. From there, it would be a relatively small task to expose this additional 'translate' field.
Comment #2
nedjoComment #3
stella commented@Nedjo: can you outline some steps on how to test this?
Comment #4
nedjoSure. It has to be tested directly in the DB as there is no UI representation.
Apply patch, run update.php, then:
1. Enable two languages.
2. Enable and configure at least one module using i18nstrings, e.g., i18nmenu.
3. Create an item that will be translated, e.g., a custom menu item.
4. Create a translation for the new menu item in the 2nd language.
5. Check the db: SELECT lid, language, translate WHERE textgroup = 'menu';
Expected result: translate = 0;
6. Update the original menu item's title.
7. Check the DB again. Expected result: translate = 1 (the item needs to be updated).
8. Through the admin/build/translate UI, update the translation for the menu item.
9. Check the DB again. Expected result: translate = 0 (the item is now up to date.
Comment #5
stella commentedOk following the steps above, I can verify that the new 'translate' column in 'locales_target' table is updated correctly.
However, the sql above is incorrect, try something like this instead:
Cheers,
Stella
Comment #6
jose reyero commentedGreat idea, committed with a slight change: renamed 'translate' field to 'status'