evenchange4/react-intl-po

Using id as msgctxt

Sand1929 opened this issue · 6 comments

Sand1929 commented

Right now, to translate the same message with two different meanings, we use the id as key. For example, if I want to translate "Normal" as both a text style and an indentation mode:

#. [homepage.text_style-0]
#. defaultMessage is:
#. Normal
#: build/messages/assets/js/scenes/Homepage/index.json
msgid "homepage.text_style-0"
msgstr "običan"

#. [homepage.indentation_mode-0]
#. defaultMessage is:
#. Normal
#: build/messages/assets/js/scenes/Homepage/index.json
msgid "homepage.indentation_mode-0"
msgstr "obično"

This works pretty well, but it means the msgid is something like "homepage.indentation_mode-0" instead of the message you wanted to translate ("Normal"). This is somewhat inconvenient, since many PO file editors now provide features like translation suggestions or basic error-checking on translations, but expect msgid to be the text you're trying to translate. So what I propose is that we add a way to specify msgctxt. For example, we could use id as msgctxt and defaultMessage as msgid:

#. [homepage.text_style-0]
#. defaultMessage is:
#. Normal
#: build/messages/assets/js/scenes/Homepage/index.json
msgctxt "homepage.text_style-0"
msgid "Normal"
msgstr "običan"

#. [homepage.indentation_mode-0]
#. defaultMessage is:
#. Normal
#: build/messages/assets/js/scenes/Homepage/index.json
msgctxt "homepage.indentation_mode-0"
msgid "Normal"
msgstr "obično"

This allows us to use defaultMessage as msgid but still translate different meanings by using id as context (msgctxt). It's also a little less confusing to translators (at least the ones I asked) since the text they are trying to translate shows up where they expect in their PO file editors.

Let me know what you think! Thanks!

evenchange4 commented

provide features like translation suggestions or basic error-checking on translations

Agree, it is important not to lose those editor features, and the msgctxt seem to be more correct way to handle this use case.
It will be great if this library can support for msgctxt, but I think there will be a big breaking changes of current solutions.

Would you like to contribute to it? Let me know. Thanks! 😀

Sand1929 commented

I'd love to! My initial thought is that we could have a message-context (-c) argument that specifies msgctxt, much like we have a message-key (-k) argument to specify msgid. That way I imagine there wouldn't be too many breaking changes, if any.

Whatever we decide on, I'm happy to work on a pull request!

evenchange4 commented

The -c argument looks good enough to me. Also, we can simply put some suggestions on the README for using -c instead of -k.

Thanks @Sand1929, any PR would be welcome! Can't wait to see this feature. 👍

evenchange4 commented

Released v2.1.0 with your changes.

  • 👍1
evenchange4 commented

Just released a patch v2.1.1 for missing argument bug (#89).

evenchange4 commented

Verify it at v2.1.1, and I add a option section of your suggestion. 💯 🚀
Close it for now. @Sand1929 Please feel free to reopen this issue if any problems occurs in your project.

  • 👍1