Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

should variables apply when defaultMessage is used? #8

Open
ArsSirek opened this issue Jun 30, 2017 · 9 comments
Open

should variables apply when defaultMessage is used? #8

ArsSirek opened this issue Jun 30, 2017 · 9 comments

Comments

@ArsSirek
Copy link

Hi,
Not sure if it is a bug, but with my usage of extract-intl, I had a case, when the locale message was actually an empty string, so we passed this null check variables had no effect, and the defaultMessage is shown in the end with {variable} as in "locale.json".

I don't know what is a right thing to do, but it seems to me that the desired result would be to have variables inserted into defaultMessage as well.

Thanks!

@cwtuan
Copy link
Collaborator

cwtuan commented Jul 2, 2017

Could you show the detail of this case? How do you use defaultMessage method?

@ArsSirek
Copy link
Author

ArsSirek commented Jul 2, 2017

Hi, I wrote an example showing my usage, wasn't sure how to provide it, so I forked and added it here in examples folder #10

And there is a branch on that fork, that shows a problem I mentioned in this issue
to reproduce you can,

  • switch to that branch, npm i
  • npm run extract-intl (that will add an gb.json to locales folder with empty strings as there is no translation yet)
  • npm run start
    now when you choose gb as locale, the messages with variables remain as they are in file, despite that we have all it needs to place the variables
    Hope that helps, best of luck!

@Panoplos
Copy link

Panoplos commented Apr 22, 2018

Actually, variables are ignored in the case of using intl.get('something', {foo}).d('something {foo} bar'), so this seems like a bug, as this call results in 'something {foo} bar'. Kind of meaningless to have defaults if this is the case.

@cwtuan
Copy link
Collaborator

cwtuan commented Apr 24, 2018

@Panoplos
It should be intl.get('something', {foo}).d(`something ${foo} bar`)

@Panoplos
Copy link

The documentation doesn't mention this.

screen shot 2018-04-26 at 12 11 41

@Panoplos
Copy link

Panoplos commented Apr 26, 2018

Or rather, it does in the API section, but why is the default variable tag spec different from the locale data?

We have a script that automatically scrapes out defaults to build the base locale, having these be different requires us to remove the $.

@cwtuan
Copy link
Collaborator

cwtuan commented Apr 27, 2018

@Panoplos
The defaultMesssage is now ES6 Template literals format. And the locale file is ICU format.

I will make this intl.get('something', {foo}).d('something {foo} bar') work, too, in next release.
Thanks for the suggestion.

@liuyiliuyi
Copy link

liuyiliuyi commented Mar 7, 2022

@cwtuan Hi, is there any progress.

@cwtuan
Copy link
Collaborator

cwtuan commented Mar 9, 2022

@liuyiliuyi
After reconsideration, I'd like to remain the current behavior for this API, because this proposal may make break changes.

And you could use react-intl-universal-extract
to extract the text in source code to locale files. It will remove the $ automatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants