Fall back xx_YY to xx if YY not present? about meteor-accounts-t9n

[softwarerero]

This should work since version 1.2.

[lfilho]

Uhm... I will test it again soon, but IIRC I did set it to pt-BR and it fell back to english. Then changed to pt and it worked.

Will double check and post my findings here. Thanks again

[softwarerero]

try pt_BR instead of pt-BR

[lfilho]

That's another thing. pt-BR is what comes from a http header, for
instance... Shouldn't we support that too?

Em sex, 22 de jan de 2016 às 18:25, Stefan Undorf [email protected]
escreveu:

try pt_BR instead of pt-BR

—
Reply to this email directly or view it on GitHub
#137 (comment)
.

[softwarerero]

Well now we have two issues into one. From the docu of version 1.2.2 (release 5 minutes ago):
"Starting from (v.1.2.2) you can also do setLanguage('en-GB') and it gets converted internally to 'en_GB'. This is usefull for taking the language string directly from an http header. "

[softwarerero]

Does falling back from xx_YY to xx still not work for you? All test's run clean.

[lfilho]

So, here's my code snippet:

if (Meteor.isClient) {
    Meteor.startup(() => {
        Tracker.autorun(() => {
            const userLanguage = 'pt';
            T9n.setLanguage(userLanguage);
            TAPi18n.setLanguage(userLanguage);
        });
    });
}

If I use const userLanguage = 'pt-BR'; or const userLanguage = 'pt_BR';, the app refreshes but login screen is still in English. But if changed it to const userLanguage = 'pt';, then it works and login screen is in Portuguese.

What am I missing?
Here are my versions:

• Meteor 1.2.1
• softwarerero:[email protected]
• tap:[email protected]

[softwarerero]

What do you mean by login sceen? Does it come from tap:i18n? You example uses just 'pt'. You should really use 'pt_BR' (or similar) like your description says.

[lfilho]

By login screen I mean regular meteor accounts ui login screen. tap:i18n
doesn't provide any translation out of the box...

I did try 'pt_BR' (and 'pt-BR'). Please re-read my previous comment. But
'pt' was the only way it worked...

Em dom, 24 de jan de 2016 às 15:13, Stefan Undorf [email protected]
escreveu:

What do you mean by login sceen? Does it come from tap:i18n? You example
uses just 'pt'. You should really use 'pt_BR' (or similar) like your
description says.

—
Reply to this email directly or view it on GitHub
#137 (comment)
.

[softwarerero]

I really do not know what to do about this. Everything works when I test it and I do not understand what you are doing exactly. Have you run the test locally (just go to tests/t9nDriver and type meteor)? Could you share a gist or something showing the problem?

[lfilho]

So, I did a meteor update just to confirm I had the lastest version.
Then I did a rm -rf .meteor/local.
Then started the app afresh: meteor.

I started debugging T9n and here's what I got:

So pt_BR is arriving at that point. But there's no pt_BR in the @maps var:

So then I get this error back: Uncaught TypeError: Cannot convert undefined or null to object

I didn't find that test folder you mentioned in your comment. Where is it exactly?

Thanks

[softwarerero]

So you trying to setLanguage 'pt_BR' but the translations is not defined. That should throw a better error (I fixed that with bc7a725). So I guess you want to create a translation pt_BR first.

[lfilho]

That's the thing, which is my original claim in this issue: shouldn't we fallback to pt if pt_BR is not present?
Use case: a user lands in our website and his http headers are set to accept pt_BR. Right now, t9n won't find pt_BR and will serve english to the user. But we have the pt language, so it would be best to show fallback to it before defaulting to english, wouldn't it?

I mean, if the user is a portuguese speaker and doesn't know english, I think re rather have a non-localized/generic version of portuguese than have it in english, wouldn't them?

[lfilho]

Also, pt-PT and pt_PT are full objects in the @maps var (see screenshot above). Wouldn't it be better not to duplicate that data and just normalize the lookups to be dash-underscore-insensitive?

Thanks

[softwarerero]

So finally I understand. You have two feature requests:

1. To be able to set a non existing language variant and instead of throwing an exception silently use a parent language. With your exapmle this sounds reasonable. Maybe we should do this and print only a warning. I'll have a look.
2. Only use one map for language synonyms. From my standpoint that would be nice to have but it's not a big deal. Open a separate issue if it is important to you, also a pull-request would be welcome.

[softwarerero]

Your first feature request is here: 9503d55. It's not released yet.

[lfilho]

Looking good! Thanks, man!

[softwarerero]

I just released version 1.3. Please give it a try.

[lfilho]

I'm moving to a new country and new job the next days, I'll give it a go in a few weeks. But feel free to close this one.

Thanks a lot! If I notice something wrong I'll post again here :)

All the best

[softwarerero]

Great. Reopen it if you still find an issue.