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.

CommentFileSizeAuthor
#1 i18nstrings-translation-status.patch4.37 KBnedjo
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nedjo’s picture

Status: Active » Needs review
FileSize
4.37 KB

Here'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.

nedjo’s picture

Issue tags: +i18n sprint
stella’s picture

@Nedjo: can you outline some steps on how to test this?

nedjo’s picture

Sure. 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.

stella’s picture

Ok 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:

SELECT t.lid, s.source, t.language, t.translate from locales_target t, locales_source s WHERE s.textgroup = 'menu' and s.lid = t.lid;

Cheers,
Stella

Jose Reyero’s picture

Status: Needs review » Fixed

Great idea, committed with a slight change: renamed 'translate' field to 'status'

Status: Fixed » Closed (fixed)
Issue tags: -i18n sprint

Automatically closed -- issue fixed for two weeks with no activity.