4 ms·

The comparison with gettext is really interesting: https://github.com/projectfluent/fluent/wiki/Fluent-vs-gettext https://github.com/projectfluent/fluent/wiki/F

The comparison with gettext is really interesting: https://github.com/projectfluent/fluent/wiki/Fluent-vs-gettext https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette... Especially the advantages and drawbacks of using the source string as a message identifier, compared to a developer provided ID. I'm wondering if fluent has something similar to xgettext, to extract the IDs from the source code? Edit: Looks like there is some discussion about extraction here: https://github.com/projectfluent/fluent.js/wiki/React-Bindings-Discussion https://github.com/projectfluent/fluent.js/wiki/React-Bindin...

stasm 8y ago
There's a tool written by a Udacity developer which can be used to autoextract copy from React source code: https://github.com/udacity/fluent-react-utils/tree/master/packages/extraction https://github.com/udacity/fluent-react-utils/tree/master/pa...
- ngrilly 8y ago
  I was thinking of something along this line. Thanks!
olau 8y ago
Don't take the comparison at its face value, it's clear to me that whoever wrote it isn't really familiar with gettext, or deliberately talking it down. Yes, it's sort of ancient, but the problems mentioned can be solved. And using the source string as ID is a pretty clever trick. Of course, there are some downsides, but there are certainly also downsides with separate IDs. Having said that, Fluent looks interesting.
- zbraniecki 8y ago
  Hi! Thank you for your feedback. I'm one of the authors of Fluent, and this wiki article. I have, in fact, been using Gettext for quite a few years, but of course, as you pointed out, I am also biased. If you have suggestions on how to improve the article to better represent the reality, please, file an issue and provide a PR! Our goal is to express our design differences, but we don't want to mislead anyone!
- ngrilly 8y ago
  The downside of using separate IDs is that the developer has to "name" each string shown in the user interface, instead of just using the source string as an ID. And as you know, naming things is hard ;-)
  - zbraniecki 8y ago
    Yes, naming is hard, but, to quote the previous commenter "this can be worked around" - you can `slug` any string if you want to. We prefer to think of the ID as the base of the social contract between the dev and the localizer. This enables a lot of fine tuned control over string invalidation.
    - ngrilly 8y ago
      Considering the translation ID as a "slug" is a good tip to ease choosing the ID. Thanks!
aardshark 8y ago
This comparison mentions that in gettext, using the source string as a message identifier "makes it impossible to introduce multiple messages with the same source string which should be translated differently." It's rather disingenuous to say this without mentioning that in gettext, the actual identifier is a combination of the source string and the string context, which is blank by default. But the context can and should be provided in cases where disambiguation is required. https://www.gnu.org/software/gettext/manual/html_node/Contexts.html https://www.gnu.org/software/gettext/manual/html_node/Contex...
- zbraniecki 8y ago
  Thank you! That's a good feedback. In our experience of working with the gettext based localizations we noticed that developers almost always omit the context and in result localizers are stripped of the ability to distinguish the message variant which makes them have to ask the developer to introduce it. This, in turn, breaks the design principle #1 of Fluent - https://github.com/projectfluent/fluent/wiki/Design-Principles https://github.com/projectfluent/fluent/wiki/Design-Principl... I'll update the Wiki to reflect that!

stasm 8y ago

There's a tool written by a Udacity developer which can be used to autoextract copy from React source code: https://github.com/udacity/fluent-react-utils/tree/master/packages/extraction https://github.com/udacity/fluent-react-utils/tree/master/pa...

ngrilly 8y ago
I was thinking of something along this line. Thanks!

olau 8y ago

Don't take the comparison at its face value, it's clear to me that whoever wrote it isn't really familiar with gettext, or deliberately talking it down. Yes, it's sort of ancient, but the problems mentioned can be solved. And using the source string as ID is a pretty clever trick. Of course, there are some downsides, but there are certainly also downsides with separate IDs. Having said that, Fluent looks interesting.

zbraniecki 8y ago
Hi! Thank you for your feedback. I'm one of the authors of Fluent, and this wiki article. I have, in fact, been using Gettext for quite a few years, but of course, as you pointed out, I am also biased. If you have suggestions on how to improve the article to better represent the reality, please, file an issue and provide a PR! Our goal is to express our design differences, but we don't want to mislead anyone!
ngrilly 8y ago
The downside of using separate IDs is that the developer has to "name" each string shown in the user interface, instead of just using the source string as an ID. And as you know, naming things is hard ;-)
- zbraniecki 8y ago
  Yes, naming is hard, but, to quote the previous commenter "this can be worked around" - you can `slug` any string if you want to. We prefer to think of the ID as the base of the social contract between the dev and the localizer. This enables a lot of fine tuned control over string invalidation.
  - ngrilly 8y ago
    Considering the translation ID as a "slug" is a good tip to ease choosing the ID. Thanks!

aardshark 8y ago

This comparison mentions that in gettext, using the source string as a message identifier "makes it impossible to introduce multiple messages with the same source string which should be translated differently." It's rather disingenuous to say this without mentioning that in gettext, the actual identifier is a combination of the source string and the string context, which is blank by default. But the context can and should be provided in cases where disambiguation is required. https://www.gnu.org/software/gettext/manual/html_node/Contexts.html https://www.gnu.org/software/gettext/manual/html_node/Contex...

zbraniecki 8y ago
Thank you! That's a good feedback. In our experience of working with the gettext based localizations we noticed that developers almost always omit the context and in result localizers are stripped of the ability to distinguish the message variant which makes them have to ask the developer to introduce it. This, in turn, breaks the design principle #1 of Fluent - https://github.com/projectfluent/fluent/wiki/Design-Principles https://github.com/projectfluent/fluent/wiki/Design-Principl... I'll update the Wiki to reflect that!