Translations with variables stopped working on production after update about js-lingui HOT 9 CLOSED

Coolio! I'm just working on the fix, should be ready in an hour. Thank you for your feedback 👍

from js-lingui.

This is related to #65. The CLI doesn't know, that message IDs are translations for cs language.

I'm thinking about another config variable: sourceLanguage. When set, translations are taken from message ID for given language during compile. What do you think?

It also means that you'll never get warning for missing translation for that language, but I guess it doesn't matter, because you're using source anyway.

from js-lingui.

Well it has to be working without translations by showing the original, so it could help the translator & don't break the app design before translations are added.
So your solution would be adding sourceLanguage: 'cs' to the config, and then it would show the original for Czech language (but not the others)? What about showOriginalWhenMissing ?

from js-lingui.

So you would like to see Czech source string even for other languages? 🤔

I'm thinking that maybe it should be the default behavior. When developer what's to get an error about missing translation, they can use lingui compile --strict. Otherwise, the source string will be used, because missing translation should never happen in production (I guess it's better to see well-formatted message in wrong language, rather than unformatted message in correct language).

from js-lingui.

I guess the sourceLanguage config is still useful when you use natural language in message IDs. Usually it means, that one message catalog will always be untranslated (the source one - cs in your case) and you don't want to get an error when validating missing translations.

from js-lingui.

it's better to see well-formatted message in wrong language, rather than unformatted message in correct language

Yes.

So you would like to see Czech source string even for other languages?

For this project, yes. English and other languages will be only marginally used and a few missing translations will not be a problem (of course we will try to have always 100%, but its better to have a minor tooltip/notification in Czech than an unformatted string).
And for a next big project (there will be a team of several devs), that I had also proposed lingui-js to be used 😊, we will use English language as default and we will like to show English messages, if eg. a Spanish one would be missing. We will likely use IDs tho, so this is not yet the problem.

from js-lingui.

Awesome! And yes, sourceLanguage is still useful, if we would add translation validation into our CI. I already have extract & compile there, so no message should be unformatted, even if someone forgot to do it before pushing.

from js-lingui.

Fixed in [email protected]

Would you like to share the name of your company so I can present it in README as a social proof?

from js-lingui.

Also, new CLI options published in docs

from js-lingui.