how to capture keys from data rather than static templates?

[dcsan]

mf_extract scans the static files and that's fine for baked in UI strings

I have a lot of english content coming from a database, and would like to use the webUI to manage these translations.

but only things that exist in mfExtract.js show up in the /translate UI. if i extract again, removed:true gets set and any previous stings disappear from the UI

is there a way to add extra strings on the fly for translation? ie when the app is running, if it hits a string that is not translated I can then add this to the DB for translation.

I had a look at manually adding to the mfStrings collection, but this seems to create an empty line. what is the minimum that is needed to add a new string to the translation UI? do I also need to update/create an entry in the mfRevisions?

db.mfStrings.insert(
    {
        key:'test3',
        lang: 'en',
        string: 'EN this is test 3'
   }
)

[dcsan]

OK this looks to be one way to do it;

mfPkg.mfStrings.insert({
  key:'test5', 
  lang:'en', 
  text:'test 5 en' 
})

this will create a string for translation in the webUI

[DSpeichert]

I would like to point out that this package is mainly meant for translating the application in the most efficient way. Currently there is a way to do that as you have found out but in order to increase performance and decrease clutter, we plan to separate DEV mode (with translation UI and collections) from the core of the package. This will make the translations static and unchangable for deployed apps. So all I want to say is that if you need fully dynamic translations created on-the-fly, this package might at some point divert too much from that.

[dcsan]

presumably we could have a DEV mode deployment too tho? then at least we could have some admin only server instance where trusted editors can work. fully open crowdsourced editing would be my preference tho, just with the abilty to ACL that.

[gadicc]

Yeah, sorry, it gets a bit confusing with all the different use cases, but yes, you'll still be able to add the mf:ui package, or whatever we end up calling it, to production apps. Crowd sourced translation will always be supported, and ACLs are already supported (through custom allow/deny functions, Meteor-style).

Back to the original question, as Daniel mentioned, the supported use of this package is for static site translations, not dynamic content. You probably don't want or expect your users to be posting MessageFormat strings with ability to specify variables :>

Having said that, I do have a (currently private) package that I use on two production sites for translating dynamic data [from users], and have been considering making this another optional sub-package of the messageformat toolset. I hadn't thought about integrating the translation UI with it until now, but there's no reason we can't do it. Note that with dynamic data, I store translation data with each document... and there are various helper functions to easily integrate this into existing app logic.

[dcsan]

interesting, so you have a solution for managing translated collections. Maybe you saw the tap18 which is split into two projects:

• https://github.com/TAPevents/tap-i18n
• https://github.com/TAPevents/tap-i18n-db

There's benefits to managing translated content separately, rather than embedded since you don't end up translating stuff twice if its referenced in two places?

The other crowdsourced translation use case is not with a separate UI at all, but inline translations. Like "editable area" for less techie users who may do a drive-by translation or two... Duolingo has an interesting UI for this