rxaviers / react-globalize-compiler

I18n support for React applications using Globalize
MIT License
5 stars 2 forks source link

Support message descriptions #6

Open alunny opened 9 years ago

alunny commented 9 years ago

When using default messages for strings, it's useful to have descriptions for strings, especially short strings. For example, if I have:

Globalize.formatMessage('Close');

then react-globalize-compiler will extract that as,

{ "Close": "Close" }

and the translator won't know, for instance, if that means "dismiss" or "nearby", which are probably not the same word in the other language.

If we had an option like:

Globalize.formatMessage('Close', { description: 'dismiss the active dialogue' });

It would be much easier to deal with, and Globalize itself could ignore the key (or we could even strip it out for runtime builds, as a further optmization).

I'm not sure what format the compiler should output it as though. @KL-7, any ideas?

KL-7 commented 9 years ago

I guess in cases where you provide a description, you could extend the syntax and instead of

{ "Close": "Close" }

use something like

{ "Close": { "message": "Close", "description": "dismiss the active dialogue" } }

Replacing a string with a hash is, of course, not ideal, but I don't see any other way if you want to provide more meta-data for each string (which is definitely a good thing).

Also, just to make sure I didn't miss anything, will the hash that you get in the end map a string to itself, as "Close" to "Close" in your example, or will it map a generic string name to its English version, e.g., "CLOSE_BUTTON_LABEL" to "Close"? If it's the latter, which I hope it is, you can usually encode a little bit of context in the string name (we call it meta-key in our app) and avoid the need of having a separate description. Still, being able to add a more detailed description is always nice.

rxaviers commented 8 years ago

I understand the importance of the message descriptions to the translators, so I think the extra bytes in the JSON files are completely worthy. Although, the same extra bytes in the source code could represent dead weight.

How could we solve this problem? Delegate the cleanup to the bundler? Is there any sane alternate way of declaring them in the source code? For example, by using comments?