livecode
[WIP] Multi-language support for IDE interface
This patch build a multi-language architecture for LC IDE interface. I've apply it to the menubar. Next step is to translate Script Editor.
Josh - thank you. About time someone did this. My only concern is with the heavy coupling between the json file and the code (in the menubar here as an example) that retrieves the text. I'm worried that this may create maintenance issues in the future, with having to keep multiple files in sync. I'd be more comfortable with a function in the library that retrieved the menu as an array and returned it to the caller, as in
function getMenu pObject, pMenu --returns an array of pObject:pMenu from gLanguage end getMenu
...and then the menubar would dispatch a call that function and populate its menu from the resulting array.
@HedgeHao apparently some plans have been made quite some time ago on how localization should be implemented. We will dig them up and post here to aid discussion on this PR. It was before I joined the company so I don't know the details.
From my perspective I'd like to see a library that can be re-used in user projects to load a string map for a language and localize strings. That would mean creating a library in the engine repo in extensions/script-libraries. It can then have its own set of tests etc.
I'm not overly convinced we need to have a map that contains information about where in the IDE the string is used. Just english -> other language should be enough and if it's not in edge cases then we can easily add a tag to the english side. FWIW I think following the model and files of the mac/ios localization would be a good plan given the existence of those files is used to determine app support for locale on those OSs. Also I would suggest one of the first places to start would be to look at making mobileCurrentLocale a fully cross platform currentLocale function so there's no need for a preference.
- Windows use GetUserDefaultLocaleName
- Linux we already do
setlocale(LC_ALL, "");inplatform_mainso we just need to hang on to the returned locale string. - Mac can reuse the iOS code.
I was poking around and stumbled across this:
function revIDELocalise pString, pSubstitutions
It currently doesn't do any actual localization, but it is called just over 80 times. It is a part of revidelibrary.8.livecodescript (where most of the calls are). From the above discussion, it would seem that performing a lookup to translate pString before including the other data would work.
There is also function revIDELocalisedString but all 16 uses of that (and a couple of variations) are commented out. (revmessageboxbehavior.livecodescript) I looked at that code and since the original calls are there, it would be pretty easy to convert them to the other format. Although pSubstitutions is expected to be an array and some of the commented out versions use a string. Since we could just check the parameter type in the function, it would be easy to overload for both string and array.
