[V2] trouble with msgfmt.setLocale

[Maxhodges]

Use msgfmt.setLocale(locale) to set the locale.

you sure?

msgfmt.setLocale('jp')
VM1035:2 Uncaught TypeError: msgfmt.setLocale is not a function(…)

[gadicc]

That's weird! What does "console.log(msgfmt.setLocale)" show?

[gadicc]

Also, that's on the client, right? You can't setLocale on the server, since generally you want the result to depend on the client's locale... msgfmt usually picks this up automatically (in methods & public functions) so no need to set by hand.

[gadicc]

That's weird, there it's defined but returning a different module?
I meant though console.log(msgfmt.setLocale) and not console.log(msgfmt.setLocale('jp'));

What else is coming up your console? Can you show the full output including all debug messages?

[Maxhodges]

sorry my last post was a mistake (was from localhost)

you can see the issue here on staging

https://wretestcustomer-47526.onmodulus.net/

[Maxhodges]

it's weird. I only refreshed the browser and now it's not generating that error. But after I set, it's reads back the wrong locale

msgfmt.setLocale('jp')
t {name: "msgfmt", _events: Object}
msgfmt.locale()
"en"

[Maxhodges]

gonna try and deploy again

[gadicc]

Slick looking site!

Sorry, the console.log output was actually ok (where it returns the logging stuff). It could definitely return something more useful but it's not a bug.

The issue seems to be that the 'jp' locale doesn't exist on that site (you can see immediately from the top of source of the page). Did you save mfAll.js from the /translate page before deploying? (or are you doing crowd translation?)

[Maxhodges]

I wanted to deploy to staging so that a Chinese staff member can add the translations. Then we'll move the mfAll.js from staging to production. is that a reasonable plan? Once it's on production do we need to edit any translations on the staging site and copy to production forever? or is there a way to lock-down the translation tool or something? Not sure what is the best practice. We haven't gotten this far before ;)

[gadicc]

Mazel tov! Hehe.

Yeah the v1 docs are still relevant for security, see http://messageformat.meteor.com/docs#security. You just use Meteor-inspired mfPkg.webUI.allow() and mfPkg.webUI.deny() callbacks. Then you can do translation directly on production, by checking user credentials first.

But it sounds like you've already done some jp translations before, so where are they? :)

[gadicc]

Btw, I can't recall which issue it was now, but next on my list is some improvements on the translation UI, for sort order etc.

[Maxhodges]

i've renamed the keys a few times, so there is a lot of junk in the database. When keys are removed I see they are 'marked for delete'. How do you actually clean them out? Do I just need to purge the mfAll.js file AND delete the database collection?

The tool issues were documented here
https://github.com/gadicc/meteor-messageformat/issues/created_by/Maxhodges

Thanks!

[gadicc]

Umm, yeah, for now. By the final there will be tools to help with these kinds of things (you could just leave them in until then I guess). IIRC deleted strings already shouldn't be served to the client, but we were trying to decide exactly how far to make use of them, e.g. should translations depending on deleted strings also be deleted, be shown as being deleted (because their dependency was deleted), and maybe even show when this happened and by who.

Btw, some of those issues you point to should be fixed by now? Can you confirm?

[Maxhodges]

is the code for your messageformat examples app in a repo? Maybe I could search that code for mfPkg.webUI.allow() to better understand how to implement security

EDIT: ah I see it's not locked down!
http://messageformat.meteor.com/translate

[Maxhodges]

I tried to just slap in some course security permissions for starters

Meteor.startup(function () {

    // if Meteo
    mfPkg.mfStrings.allow({insert: mfPkg.webUI.allowed, update: mfPkg.webUI.allowed, remove: mfPkg.webUI.allowed});
    mfPkg.mfRevisions.allow({insert: mfPkg.webUI.allowed, update: mfPkg.webUI.allowed, remove: mfPkg.webUI.allowed});


});

oddly it runs locally but not when deployed

TypeError: Cannot read property 'allowed' of undefined
    at app/lib/config/initMessageFormat2.js:3:43
    at app/lib/config/initMessageFormat2.js:7:3
    at /mnt/app/programs/server/boot.js:222:10
    at Array.forEach (native)
    at Function._.each._.forEach (/mnt/app/node_modules/underscore/underscore.js:79:11)
    at /mnt/app/programs/server/boot.js:117:5

[Maxhodges]

maybe the security docs are wrong? should be allow not allowed?

[Maxhodges]

is this the right idea? unfortunately none of my console.log statements are running so I guess we still got something wrong

if (Meteor.isClient) {
    mfPkg.webUI.allow({
        insert: function () {
            console.log('allow mf client');
            return Users.isStaff(Meteor.userId());
        }, update: function () {
            console.log('allow mf client');
            return Users.isStaff(Meteor.userId());
        }, remove: function () {
            console.log('allow mf client');
            return Users.isStaff(Meteor.userId());
        },
    });
} else {

    mfPkg.webUI.allow({
        insert: function (userId) {
            console.log('allow mf svr');
            return Users.isStaff(userId);
        }, update: function (userId) {
            console.log('allow mf client');
            return Users.isStaff(userId);
        }, remove: function (userId) {
            console.log('allow mf client');
            return Users.isStaff(userId);
        },
    });

}

[Maxhodges]

Btw, some of those issues you point to should be fixed by now? Can you confirm?

I ran meteor update but msgfmt didn't appear in the list of updated packages. Did you deploy?

[Maxhodges]

Btw, some of those issues you point to should be fixed by now? Can you confirm?
fixed where? I see no update. @gadicc

[gadicc]

Oh wow, I'm really behind, sorry! :(

allow() and deny() just take a single function, since we only really care about if someone can or cannot modify translations. It's explained in the docs but I agree it could be a lot clearer. I didn't see anything there about allowed() (instead of allow()) though?

Re versions, yes, unfortunately the bad side about pre release packages in Meteor is that they don't update automatically. It kind of makes sense though since things are more likely to break without warning. These are all the latest versions:

msgfmt:core                  2.0.0-preview.12 MessageFormat support, the Met...
msgfmt:extract               2.0.0-preview.9 Extracts native / translatable ...
msgfmt:ui                    2.0.0-preview.4 messageformat: translation UI

You need to just e.g. meteor add msgfmt:[email protected] to force the update.

[Maxhodges]

Thanks sir! btw how do I know when you've released a new preview (and what the name will be)? I don't see this info in atmosphere . . .

Cheers!

[gadicc]

Yeah it's a bit difficult atm with the preview releases :( But at least you know nothing will break on a "meteor upgrade". In the issues now, any time I refer I do a new release that affects that issue, I'll tag it, e.g. see the bottom of #152 for the hint, or just the list of commits at https://github.com/gadicc/meteor-messageformat/commits/v2. Obviously this is not ideal and will be a lot better when the final release is out, but I think it's important to be clear now that we're not "release quality", which should include, e.g. https://github.com/gadicc/meteor-messageformat/issues?q=is%3Aopen+is%3Aissue+milestone%3Av2 (thankfully many of those are partially solved already).