Js-lingui: Having default language in code vs in its translation file

[ripern]

This is somewhat related to https://github.com/lingui/js-lingui/issues/276, however:

Today I have the default language strings, English, inside code as in <Trans>Some text</Trans>
and other languages in messages.po (translation files). This makes it easy when updating other languages, however if any English is changed, this is needed:
A. update code with new English
run yarn extract, which generates new strings in all translation files
B. all the translation files needs to be manually updated

I understand this could either be solved by:

1. Update English inside its messages.po but then it feels weird to have the previous version in code so perhaps better to shorten it and make it generic as in something like <Trans>welcomePage.title</Trans>
   or
2. <Trans id="welcomePage.title">Should this be empty?</Trans>

Would 1 or 2 be recommended? Any drawbacks of either?

[tricoder42]

Hey @ripern,
you're right, this is one disadvantage of using English inside code.

I usually change English copy in english translation file (e.g. en/message.po):

msgid "Some text"
msgstr "Some updated text"

This works fine for some time. I didn't have to change too many lines manually.

Using this approach, we could build an extra command which updates any changed messages in code based on message catalog. For example, if we previously had:

<Trans>Some text</Trans>

msgid "Some text"
msgstr "Some updated text"

The transformation would gives us:

<Trans>Some updated text</Trans>

msgid "Some updated text"
msgstr "Some updated text"

This is trivial for simple messages, but becomes a little bit complex for plurals and formatting. Still I believe it's doable.

The "traditional" approach is that you change the copy in source code, then you run lingui extract which detects change of message ID based on origin and then it updates message ID in catalog and flags message as fuzzy. You need to review all fuzzy message by hand to make sure the merge was done correctly. I'm planning this feature for v3, but thinking about it, maybe it's first approach better.

What do you think?

---

Edit: Yes, using custom IDs is alternative solution here. It solves some problems, but it has completely different set of problems. I used both approaches and now I prefer to keep the English in source code. This is really just a matter of taste and how you setup your translation workflow.

Would be great to document both.

[tricoder42]

I've start collecting feedback to document pros/cons of both approaches here: https://www.kialo.com/25159 Feel free to join.

[ripern]

Yes, I'm doing the "traditional" approach.
The only advantage I see with the transformation you suggested is that we remove the need for coming up with message ids, which is nice I guess but probably not worth that much.

My question was rather if it's best to do

1. <Trans>welcomePage.title</Trans>
   or
2. <Trans id="welcomePage.title"></Trans>

When you wrote

it has completely different set of problems

I assume you referred to 2 above being painful. What are those problems?

[ripern]

After evaluating this further, I see the advantages of using default language in code (like what I already have). Mainly because I realized there are more cons than pros with making up my own message ids. This means I'm also positive to your suggestion about the command that would update msgid with English msgstr as well as its corresponding string in source code. That wouldn't need to be run very often but every now and then.

Also, to answer my own question above, the syntax when using id should be nr 2.
And to give an example of a problem that occurs when using ids is that eg

<Trans id="eula.ihaveread">I have read the 
  <a href="https://someurl.org/terms-of-service">Terms of Service</a> and agree
</Trans>

generates

#: src/views/EULAView.jsx:131
msgid "eula.ihaveread"
msgstr ""

which complicates matters for the translator compared to using default language as msgid which would generate:

#: src/views/EULAView.jsx:131
msgid "I have read the <0>Terms of Service</0> and agree."
msgstr ""

[tricoder42]

Try to set "sourceLocale": "en" Lingui config. Then you should get:

: src/views/EULAView.jsx:131

msgid "eula.ihaveread"
msgstr "I have read the <0>Terms of Service and agree."

[ripern]

That worked, thanks!

Yes, using custom IDs is alternative solution here. It solves some problems, but it has completely different set of problems.

What are some of those problems? Are there for example features that work when using the "traditional" approach but not when using custom ids?

[dimensi]

It would be cool if it was possible to specify in the compile command that the source locale should be omitted.
I use
<Trans id="someId">Text</Trans> or t('someId')`Text`
I already have the original text, why should I download it again import sourceLang from 'locales/sourceLang/messages.js?

[olafura]

@tricoder42 If I try your trick then I get a duplicate entry in the extract step. Which one is used and can you turn off the duplication?

[tricoder42]

@olafura Could you please post an example file, config and extracted messages?

[olafura]

@tricoder42 I'm not able to replicate it must of been something I did incorrectly. Seems to work fine ;)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.