gadicc
Support for not specifying keys (like gettext)
Hi Gadi,
While converting my app's current UI strings to mf helpers, I feel it's a little painful to due with keynames, because of the following reasons:
a. Thinking which keyname to use may slow down the coding 'flow'
For a keytext, we often come up with one effortlessly, since it's our natural language. However, to have a good keyname, we need more time to think. It may just be a couple of seconds, but I'm feeling it's a blocking obstacle in my coding flow.
--> Is there a way to provide only one argument - the keytext, in the position of a keyname - to an mf helper?
I tried adding {{mf 'This is actually a keytext that I use as a keyname'}} in my template and running mf_extract. However, I can't see that string at /translate page. It looks like the /translate page only displays items that have keytext. Is there any way to make the /translate page display the above string (display the keyname instead of keytext)?
I understand that using a helper this way has some drawbacks as pointed out at http://messageformat.meteor.com/docs#whyusekeys. However, I think it's really worth it.
b. There's a possibility that developers may accidentally use the same keyname for different strings.
--> Do you have any best practice to avoid this situation?
I hear you. I've thought about it before. I guess it would be nice to offer it up as a choice to developers if they've read the http://messageformat.meteor.com/docs#whyusekeys doc.
To just allow it as is though is very problematic... you could add in a comma, and lose all your old translations. The only way we could allow this is if we use the gettext algorithm, which I actually had trouble finding, but I guess I should just look in the source. This has some heuristic based on similarity between changed strings and I believe the file they're in, and possibly approximate position.
I'm happy to leave this issue open and take a stab at it when I have some free time. Unfortunately that won't be for a while and you're stuck with keys for now :) But ultimately, keys will still help you avoid the inevitable loss of translations, albeit very rarely. And key names can sometimes help translators by giving them context, especially for short strings.
Your other issue is a good point and I opened a seperate issue for that, above.
Oh, you asked for best practices, so, some example keynames :)
MENU_HOME MENU_PROFILE DASHBOARD_WELCOME NOTIFY_EMAIL NUM_RESULTS SUBSCRIBE_TOOLTIP
For a lot of these, it's quite obvious what the keytext will be. Anways :)
A very thorough response as always, Gadi!
My team and I are discussing a scheme for keynames now.
Thank you and have a nice day!