'Internationalize' projects

[ReindlWolfgang]

Hello,

first of all: it's good, the forum remembers me after all the time. I'd had forgotten my acess-data.
second: Maybe I just used the wrong searching strategy and there's an answer to my question anywhere in the forum

OK:
I start for the humptieth time to write some application, and I do it with a German-language interface because it's easiest for me to do so. If ever the application gets usable I think it might be interesting to some people around the world, so a German interface will be not so good.
Most Mac-applications have folders named "*.lproj" within their package "*" being the shortcut of different languages. Those applications "get translated" to the chosen language of the system automaticaly as soon as there's a matching folder *.lproj. Does LiveCode support that technology?
What about cross-compilated versions of my application to winDOS or Linux? Will they be able to use the information from the *.lproj to run in the local language (if there's a translation)?

And there's some other points with internationalisation of applications, e.g.:
- format of date: in Germany it's dd.mm.yyyy, in USA mm/dd/yyyy and there are other formats as well in the world. I think about storing the date as a timestamp, but it should be possible to enter it and read it according to the local manner.
- Similar problem with the decimal: German speaking countries use a "," to separate decimals, English speaking countries use a ".". On a Mac it's written in the system prefs, what format is used. Is LiveCode able to read that information from the system and make use of it?

Sorry for my bad English
Wolfgang

[shaosean]

If the "*.lproj" files are just plain text (or XML) then you should just be able to use them like any other file on non-Mac systems (you will need to duplicate the Mac automatic UI update to the new language though)..

The info you are requesting about the date and currency features were a topic of discussion on the mailing list a couple months ago and it seems there was a semi-solution posted for Mac OS X (just for the currency, not the date)

http://lists.runrev.com/pipermail/use-l ... 53865.html

If you are able to, you can easily get the information from the system through an external (which is the route I took)..

[ReindlWolfgang]

If the "*.lproj" files are just plain text (or XML)

I guess, you're not a Mac-user?
When you right-click on an application-file you can loock into that application's "Contents". One of those is a folder named "Resources" containing some files and some folders, among them there are those Language.proj folders containing some files and again some other folders.
One of that files is named "Localizable.strings" an can be opened with TextEdit to show:

(from TextEdit, English.proj - first 5 entries):
/* Menu item to make the current document plain text */
"&Make Plain Text" = "&Make Plain Text";

/* Menu item to make the current document rich text */
"&Make Rich Text" = "&Make Rich Text";

/* Menu item to cause text to be laid out to the size of the currently selected page type */
"&Wrap to Page" = "&Wrap to Page";

/* Menu item to cause text to be laid out to size of the window */
"&Wrap to Window" = "&Wrap to Window";

/* Menu item to make the current document editable (not read-only) */
"Allow Editing" = "Allow Editing";

The same from German.proj of the same application:
/* Menu item to make the current document plain text */
"&Make Plain Text" = "In reinen Text umwandeln";

/* Menu item to make the current document rich text */
"&Make Rich Text" = "In formatierten Text umwandeln";

/* Menu item to cause text to be laid out to the size of the currently selected page type */
"&Wrap to Page" = "Seitenränder einblenden";

/* Menu item to cause text to be laid out to size of the window */
"&Wrap to Window" = "Seitenränder ausblenden";

/* Menu item to make the current document editable (not read-only) */
"Allow Editing" = "Bearbeitung zulassen";

Any string used in a Program is represented in this file or in one of a myriad similar files.
Some of that files seem to contain binaries beside the strings (again from TextEdit, German, another file):

€Ù]keywordsFieldÙrstJuvwxyzNV-ˆ€€C€ €V€K€Ä€³€U€ÛÓ>‹’€B¦!©#$ €:€6€X€<€=€9¦x(¯xxx€N€@€Y€N€N€NØrstuvwxyzœ|-Ÿ €€C€ €Þ€1€³€Ý€ß_value: selection.comment_selection.commentÓ>¥²€B¬ !"#$%&€4€5€6€7€8€9€:€;€<€=€>€?¬()(((±±(±±)(€@€A€@€@€@€€€@€€€A€@ØrstuvwxyzÂ|ŒÅÆ€€C€ €â€1€Q€á€ã_value: selection.author_selection.authorÓ>ËØ€B¬ !"#$%&€4€5€6€7€8€9€:€;€<€=€>€?¬()(((±±(±±)(€@€A€@€@€@€€€@€€€A€@Ôruv2Œ-î€m€Q€³€…Ôruv2òî€m€‡€€æ_propertiesPanel×rstuvxyóôzö€€C€€ê€é€ €è_ contentObject: inspectedDocument]contentObject_inspectedDocumentÔrûüýüÿXNSMarkerVNSFile€î€d€í€ì_NSToolTipHelpKeyo=Titel des Dokuments - für reine Textdokumente nicht verfügbarÒ78¢;_NSIBHelpConnectorÔrûüýŒ €î€Q€ð€ìo?Autoren des Dokuments - für reine Textdokumente nicht verfügbarÔrûüý€î€\€ò€ìoNName der Firma oder der Organisation - für reine Textdokumente nicht verfügbarÔrûüýP€î€E€ô€ìoBHinweis zum Urheberrecht - für reine Textdokumente nicht verfügbarÔrûüý}€î€ €ö€ìoSSchlagwörter für die Dokumentbeschreibung - für reine Textdokumente nicht verfügbarÔrûüý-!€î€³€ø€ìo3Kommentar - für reine Textdokumente nicht verfügbarÔrûüýµ'€î€}€ú€ìo?Betreff des Dokuments - für reine Textdokumente nicht verfügbarÒ>+,€ÿ¯!n"ɼյ'+“Â,-zü¾W–$Z)P}.4‚ŽHIòªŒŠ€¢€€_€€€º€}€Ÿ€©€T€\€®€³€ €d€¶€H€¬€š€€¤€E€ €·€“€§€g€€ü€þ€‡€±€Q€ Ò23P€€ý]NSApplicationÒ23P€€ýÒ78V ¢ ;Ò>+Y

I think, it will be extremely hard to do those files non-automated.

then you should just be able to use them like any other file on non-Mac systems (you will need to duplicate the Mac automatic UI update to the new language though)..

If there would not be the word "if" ... I would be a Millionair

The info you are requesting about the date and currency features were a topic of discussion on the mailing list a couple months ago and it seems there was a semi-solution posted for Mac OS X (just for the currency, not the date)

http://lists.runrev.com/pipermail/use-l ... 53865.html

Thanks for that.

Wolfgang

[bangkok]

The "ressources" concept doesn't exist on Windows.

So, it might be better to manage the "internationalization" of your app, from the app itself.

It's very easy to handle this with a few custom properties and scripts (for button labels, content of label fields, menus etc.)

This can be done in the openstack handler for instance, for all your cards, or a few of them, etc.

See the example.

[shaosean]

I guess, you're not a Mac-user?

You guess wrong, but I personally have no need of multiple languages even though I had started a project long ago to give Rev native multi-language support..

[Mag]

Great topic. I add my two cents

Because we usually don't know all the languages we would like to have in our app , I think it's a good choice to put all the localized strings in one place so it's more easy to handle them when you need to give them to some native language speaker person to translate them.

Here is how I I'm doing it for a project, but there should be better ways... I create a field for each language whic contains all the localized strings. Each line contains a string:

Code: Select all

1.
2.
3. -- Welcome view --
4. Welcome text line 1 =Welcome.
5. Welcome text line 2 =This app helps you etc etc.
6. Continue button =Continue
7.
8.

Then in each card I'm using a function to localize the buttons and fields

Code: Select all

on preOpenCard
   -- localization
   put localizedString(4) into field "welcomeMessage"
   put return & localizedString(5) after field "welcomeMessage"
   put localizedString(6) into field "continueButtonLabel"
end preOpenCard

To localize alert box, I'm using this:

Code: Select all

put localizedString(79) into Mquestion
ask Mquestion

Here is the function (in stack script):

Code: Select all

function localizedString theLineNumber
   set itemDelimiter to "="
   put  (item 2 of line theLineNumber of field "english" of cd "localizations" of stack "resources") into theString
   set itemDelimiter to comma
   return theString
end stringaLocalizzata

Then you need some code that detects the system language to automatically switch the language to use by using the function mobilePreferredLanguages(). Users prefer to avoid to deal to things like "Choose your language" and such.

One thing to keep in mind is that when you upload the app in App Store, you need that all the language you support are correctly listed in the app description under the appropriate App Store field which I think, but I'm investigating about this point, is build based on the files you have in the app engine folder (es.lproj/Localizable.strings, fr.lproj/Localizable.strings etc..). See this topic to learn more http://forums.runrev.com/viewtopic.php?f=8&t=11679.

All corrections, advices and suggestions to improve this method are welcomed!

[Mag]

OK, here is a possible implementation for dinamically change the language based on user settings. It works with the idea to have all the strings for a particular language in a single field on the resources sub-stack (see post above for more details).

Code: Select all

function localizedString theLineNumber
   
   if the environment is mobile then
      put mobilePreferredLanguages() into tLanguages
      put char 1 to 2 of tLanguages into languageShort -- to catch also en-GB etc
      
      if languageShort = "it" then
         put "italian" into fieldName
      else
         put "english" into fieldName
      end if
      
   else
      put "english" into fieldName -- for development
   end if
   
   set itemDelimiter to "="
   put  (item 2 of line theLineNumber of field fieldName of cd "localizations" of stack "resources") into theString
   set itemDelimiter to comma
   return theString
end localizedString

Feel free to change it or suggest improvements.

[jacque]

Localization is usually managed in custom property sets. Create one set per language. Each key of the set can be a field or object name, and the values of each key can be the data that applies to the field. When changing languages, you just set the custom property set to the language you want to use:

set the custompropertyset to "English"

Then run a handler that loops through the keys and sets the values of the field content.

[Mag]

Hi jacque, yes this is one of the ways. Most people like to do in that way.

PS
I personally don't like to have localization strings scattered throughout the stack but I prefer to have all of them in one place for the reason I wrote in my previous post.