What would be the best approach to translate an app?

eg. to translate "> New Alarm", "> Save" and "> Back" in alarm.js to german and other languages?

We have locale.lang, but using this naivly would mean to include all language strings in the .js file, which might be bad for memory...
Would it be better to put the strings in a json file, read the file on startup, take only the current language strings and throw away the rest?
Or one json file per language?
Any other ideas to optimize this?

Mon 2020.03.30

Are the responses here a suitable explanation?

Posted on Wed 25th, March 2020 What does the Languages app and how can it be used in apps

@Robin : Unfortunatly no, my issue from above is not addresses there.

I guess a crowd approach here would be the best solution. Having a separate file for the program and the strings used would enable localization. Then the app store would need to support localisation too and allow to upload the language file separately. Whether the language file would overwrite the default file should be optional, but those few strings should not pose a memory issue in most cases.

As I'm sure you noticed, we currently do translation like this: https://github.com/espruino/BangleApps/blob/master/apps/locale/locale.html#L74

translate: s => {s=""+s;return locale.trans[s]||locale.trans[s.toLowerCase()]||s;},

The way it's handled, that translation array gets loaded into RAM as soon as locale is used.

However, it could easily be modified to:

translate: s => {
var trans = { ... actual translation data here ... }
s=""+s;return trans[s]||trans[s.toLowerCase()]||s;},

Since function code is kept in Flash, this would be nice and tidy and would allow translation without a massive memory usage hit.

And I think maybe we could do something smarter with the translation, like:

• Handle capital letters (No/no) specially (could be done with regex)
  
• Match on part of the string (so just New Alarm from > New Alarm could get picked up)
  

@UweD: What would you (nd the others) suggest: One file per program and language or one file per programm with all languages inside?

@Gordon: My question is more on how to obtain the "actual translation data here". In Locale you select the language on download and then only this language will be in flash. I do not really think it's feasable from usability perspective for alle programs to select the language by themselves on download. Best would be if we could obtain the language set for locale on the device during app download and then only put the selected language (or a fallback language) on the device.

I'd say one common file per language would be good, as I'm sure lots of apps will have common text, like Stop/etc.

While it'd be nice to have something per-app, realistically most apps (at least to date) get published and not updated - I don't think very many would get translated if we required per-app translations.

Just a thought here, but maybe we could have a way of defining strings in apps, like LANG("Hello") that the App Loader could parse and replace on upload rather than having to have JSON in the watch? Maybe that's too heavy though.

@DerGuteWolf sorry, I missed that latest edit...

The idea behind using require("locale").translate(text) in apps (which menu/etc does automatically) is that you only select the language once - when you upload the Language app. After that, all apps will be translated using the translation data that got uploaded to Bangle.js

@Gordon I like your idea if replacing eg LANG("Hello") on upload. You could search for the translation first in an app-specific file and if not found in a common file.
However I still don't like each app to require to have the user choose a language on upload (also this make updating the app to a new version problematic, currently if you update locale, you get always the default language not the language you selected on the upload). As I said, best would be to obtain the language set in the locale file on the device.

currently if you update locale, you get always the default language not the language you selected on the upload

Yes, that's just an App Loader issue which I've got down to fix.

But yes, if we did replace on upload then we'd have to have the App loader be able to figure out what the current language is set to. For now, it seems that if we could handle translation with the Locale/Language app that'd be preferable - that's one of the things it was intended for after all

Would

  return new Promise((resolve,reject) => {
    Puck.write("\x03",(result) => {
      if (result===null) return reject("");
      Puck.eval(`require("locale").lang`, (content,err) => {
        if (content===null) return reject(err || "");
        resolve(content);
      });
    });
  });

work in a custom html?

Yes, totally. Probably even you could ignore the initial Puck.write.