gadicc
commented
9 years ago All good :) I'm happy they're all public and address issues that others can benefit from, and only regret how limited my time is on this atm (would have loved to have gotten a stable v2 out by now, although people are using the preview releases already).
The documentation is all about v1, where basically all your current trans data is in the mfAll.js which you can save in any project to "import" it (and likewise, during deploy, gets sent to the production/staging server).
In v2, we do things a little differently because mf_extract is gone and has become automatic. Native strings at least are sent up automatically with deploy, and I think this is a pattern we'd like to continue (to make things "just work" with very little effort). As you've pointed out, there are cases where I guess this isn't the desire behaviour though, so we'll need to figure out the best way to solve that (maybe a timestamp for what should be deployed) - but I guess that's another issue.
In short, back to v1... just save your /translate/mfAll.js before meteor reset and you should be fine I think.
tvld
It is probably by design, but I wonder if we really should loose all translated text with a reset of meteor...?
For example, we translate using one test installation and move only the translation to the test and development machines. Obviously we dont want to pollute the database of production with test-data.
Is there some documentation about the best work-flow?
(sorry if I overflow you with Questions ;) )