Replies: 1 comment 3 replies
-
gettext uses GNU format while we only support ICU. I think not just plural but also select and & selectordinal will not be compatible. Furthermore the MessageFormat WG is working on v2 which would be radically different and only support XLIFF & JSON as the data format. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The issue
I would like to extract the messages and save them as
.pot
file. I hoped it would be possible with a custom formatter, but nope. Custom formatters only allow to transform JSON. PO and POT are basically the most supported formats everywhere so supporting them would be valuable.My use case was to be able to translate stuff locally using something like poedit. It offers much better experience than editing the JSONs directly.
Proposal
React-intl and original gettext APIs are slightly different, so the implementation of such formatter would be probably non-trivial, but it is possible. Here are some examples how the extracting could work. The id would be always ignored when extracting, and recomputed based on msgid (defaultMessage) and msgctxt (description) when compiling.
with a placeholder (just treat placeholders as normal text, optionally add "icu-format" tag or something):
with
--extract-source-location
:Message with description:
Message with plural (this is the non-trivial part):
Only the plural placeholder should be handled in a special way.
When extracting a message with more than one plural placeholder, the command should just crash. There's already an eslint rule to enforce to not do that.
Other forms than "one" and "other" should be ignored because the original should be always English and it has only two forms.
When compiling translated PO files to JSON, the program should generate IDs based on msgid and msgctxt. It doesn't make sense to support manual IDs in PO. The pattern could be provided via
--id-interpolation-pattern
just like onextract
.Alternatives
Why not just use GNU
xgettext
xgettext
works fine for JS, but it doesn't support JSX. It only analyses function calls. Even if it supported JSX elements, then there's special handling of messages with plural forms. Original gettext has separate function for the plural messages.Why not drop
react-intl
completely and use something likereact-gettext
There are libs like that but they aren't as well maintained.
Beta Was this translation helpful? Give feedback.
All reactions