what to do with mfAll.js ?

[dcsan]

if I have a live app with people translating through the webUI how do i gather those translations for my local deployment?

downloading mfAll.js but not sure how to use it? I added to server/ directory and it runs at startup:

mfPkg.syncAll({
  "ja": {
    "trans_string": {
      "key": "trans_string",
      "lang": "ja",

but this doesn't result in any strings inside my app, translated or not.

what else is involved to sync up translations from a live deployment?

[dcsan]

as per #66 I cannot use the mfExtract.js as I'm working with dynamic data in the templates.

but I'm guessing that the sync function needs base strings to be already created by something else?

maybe i can turn the mfPkg.syncAll into amfPkg.mfStrings.insert to recreate all the translation data?

[dcsan]

OK so it looks like I can edit the mfPkg.all and do something like this:

// change 
mfPkg.syncAll({
  "ja": {
    "trans_string": {
      "ctime": 1411584128533,

to be like

mfData = {
  "ja": {
    "trans_string": {
      "key": "trans_string",
      "lang": "ja",

then overwrite current mfStrings

function addOne(blob) {
  mfPkg.mfStrings.insert(blob)
}

mfPkg.mfStrings.remove({})
_.each(mfData.en, addOne)
_.each(mfData.ja, addOne)

but this seems like a big of a ghetto approach to managing translations from the crowd. interested to know if there's a better way? otherwise i could create a different exporter that spits out a "mfReset" or some such script.

[gadicc]

Yeah unfortunately dynamic data is not supported like this. But even with the other package I mentioned, I don't plan to support moving translations of dynamic data from production back to local... I think this is an app specific issue, usually it's unwanted to mix production and development database documents, and the developer needs to decide when it's appropriate to export and import which specific data on individual cases. (As I mentioned, with the dynamic data package, translation data is coupled with each document on an individual basis, in any event).

[dcsan]

I basically have this working as below, but not sure if this is the right API to be using:

mfPkg.mfStrings.insert(obj)

for inserting new strings on the fly. but it seems to work and create the 'en' key strings i need. not sure if it plays nice with the "mfPkg.revisions" table

Loco.checkOrCreate = (key, text, lang) ->
  text ?= key
  if mfPkg.strings and mfPkg.strings.en and mfPkg.strings.en[key]
    ## note that MF uses the vars as 2nd arg >.<
    vars = null
    res = mf(key, vars, text, lang)
    return res
  else
    obj = {
      key: key
      text: text
      lang: 'en'   # create a basekey
      template: Router.current().path
    }
    console.log('addTransKey', obj)
    Meteor.call 'addTransKey', obj
  return text or key

# server method
Meteor.startup ->
  if Meteor.isServer
    Meteor.methods({
      'addTransKey': (obj) ->
        console.log("adding transKey", obj)
        res = mfPkg.mfStrings.insert(obj)
    })

separately to manage the strings I have a couple of server routes to import/export.

Meteor.startup ->

  Router.map ->

    @route 'reload',
      where: 'server'
      path: '/loco/reload'
      action: ->
        text = Assets.getText("assets/mfStrings.json")
        doc = JSON.parse(text)
        console.log(doc)
        mfPkg.mfStrings.remove({})
        mfPkg.mfRevisions.remove({})
        _.each(doc, (obj) ->
          console.log(obj)
          mfPkg.mfStrings.insert(obj)
        )

        @response.writeHead(200, {'Content-Type': 'text/html'})
        @response.end(@params.cname)

    @route 'dump',
      where: 'server'
      path: '/loco/dump/mfStrings.json'
      action: ->
        data = mfPkg.mfStrings.find().fetch()
        @response.writeHead(200, {'Content-Type': 'text/html'})
        # @response.write("locoData = ")
        @response.end(JSON.stringify(data,null, 2))

If you think others might use this, and you'd accept a patch I could fork your package and try to merge this in. but i was a bit confused about your directory structure and ended up just adding this to my own "loco" wrapper package.

I didn't support the variables on the fly, to make stuff easier.

[DSpeichert]

@gadicc not sure how much this applies to v2?