cli/extract: update source translations

[vsnig]

This is obviously only relevant when using messages with custom IDs.

Right now if we extract messages and then decide to update them (in source code) and run extract again - it won't update the messages in catalog. It will leave initial strings and there'd be no way to update them other than manually edit the catalog.

I think it shouldn't be like that and we should update source catalog with updated messages in this case.

We can change this string:

translation: prevCatalog[key].translation,

to

translation: config.sourceLocale === locale ? nextCatalog[key].defaults : prevCatalog[key].translation,

And this leads to another issue :) (I wrote about it here) - when using minimal format with custom IDs, it extracts as 'message.id': 'message.id' instead of 'message.id': 'default message'
This can be fixed here, changing:

translation: config.sourceLocale === locale ? key : "",

to

translation: config.sourceLocale === locale ? message.defaults : "",

What do you think?

[tricoder42]

Sounds reasonable. I'm gonna take a look at this issue today. There seems to be many related issues.

[tricoder42]

@snegostup I've just created a PR, would you be interested in review? I updated your proposed solution little bit:

Instead of

translation: config.sourceLocale === locale 
  ? nextCatalog[key].defaults 
  : prevCatalog[key].translation,

there is

translation: config.sourceLocale === locale && 
prevCatalog[key].translation === prevCatalog[key].defaults 
  ? nextCatalog[key].defaults 
  : prevCatalog[key].translation,

to avoid loosing custom translations (even in catalog for sourceLocale).

[vsnig]

Thanks!

when using custom message IDs and minimal format, once catalog for sourceLocale is generated translations must be always edited manually. Even when default translation in source code is updated, the translation in catalog won't be updated automatically because there's no way to distinguish default translations from custom ones.

This is really a problem. Like a coder I'm not comfortable having multiple sources of truth (code and catalog) and would gladly have an --overwrite option that would overwrite all string in favor of ones from code. On the other hand I can imagine the case when proofreader corrects my ugly English strings (in catalog) and I need to keep them. I need to think a bit more.

[tricoder42]

It is indeed suboptimal.

What if we add interactive mode to lingui extract? When different defaults are encountered it either means the source code has changed or proofreader changed the catalog. CLI should stop collecting messages and give you two options:

• either update message in source code (manually)
• or update defaults in catalog

Options would be: code, catalog, all from code, all from catalog and the last two could probably have CLI options (--update-defaults, --keep-defaults)

[tricoder42]

In simple cases, we could also update message in code automatically. Complex messages like {value, plural, one {Book} other {<strong>#</strong> Books}} would have to be updated manually anyway (auto update seems to me too complex at the moment 😄 )

[vsnig]

Great idea. And I agree that we don't need to update code automatically, just display good message and exit. It reminds me how DBMS would react if you try to create unique index on a field and it encounters two records with same value of the field. It would just display error message and stop. Most probably you would already know why the messages are different and can quickly update whereas autoupdate would certainly be error prone and would need a lot of polishing.

This also reminds me of #200 -- we can also throw similar error message and stop when encountered different messages with same ID within code

[tricoder42]

Alright, just to narrow the problem down. This is related only to message catalog for sourceLocale in minimal format. I think --overwrite makes more sense than --update-defaults.

[vsnig]

👍

[tricoder42]

Fixed and released in v2.2.0. Thanks to all involved!