Localizing my app—but Lingua doesn’t support iOS?

[John_Balestrieri]

I’ve started the process of localizing my iOS app, and are new to XOJO’s methods—I’ve localized plenty of iOS apps with Xcode.

As I understand it, I can create localized string constants. I’m using a translation service that needs plain text—and can’t use Lingua—so it appears the path is:

1. Export Localizable Values from my XOJO project
2. Open that file in Lingua
3. Export tab delimited data
4. Translate
5. Load the tab delimited data back into Lingua
6. Load the lingua data back into XOJO.

I’m only on step 2, and things have gone missing. This is my constant:

I export the French translation for iOS and it’s not exported. It apears only mac, win, and linux are supported:

And that’s confirmed when exporting the English values:

I think the process rather convoluted anyway, so let me toss out an idea, since I’m preparing to ship an international update next week:

I create one localized string constant that returns a language and platform code:

Then I create my own text file with my localizations—in fact, I could probably reuse my xcode string files:

Then I write a bit of code that loads all the strings for the current platform and language and stores them in a dictionary, and use my own global string lookup method wherever I need a string.

To me, this seems a whole lot quicker and simpler than Lingua, right?

[Jeff_Tullin]

@John_Balestrieri

To me, this seems a whole lot quicker and simpler than Lingua, right?

It does mean you have to apply the string values to any controls when a window/screen/form is opened.
But the benefit is that you can change language at any time as a user choice, rather than hoping that the OS runs the app in the right language.

(I have many customers in ‘foreign countries’ who prefer the English text even though their machines are configured for French or German

• the menus match the English documentation,
• and my translations are probably a bit iffy)

[Jeremie_L]

Lingua doesn’t support “iOS” platform constants.
You need to set your constants as “Any” platform.

Use whatever solution seems the easiest to you. No solution is perfect, but the one that allows you to re-use existing translations is the best IMO.

I used to have everything as localised constants.
Each localised constant is préfixed with the word local

Label1.text = localHello

Then I moved to referencing localised constants with the current language code. This allows changing language on the fly.

Label1.text = localHello(currentLangcode)

Now I am using a hybrid solution that loads localisation from an online DB and fallsback to localised constants

Label1.text = OnlineLoc("localHello", localHello, localHello("en"))
//references localHello key in a dictionary,
// gets localised constant if online DB has no entry 
// defaults to English value if not translated 

---

Also all my localised constants have a default value with trailing double space characters.
It allows me to activate/hide features

If localHello.contains("  ") then
  //not translated
  button1.visible = false
Else
  button1.visible = true
  button1.caption = localHello
End if

I had to come up with this solution when adding a feature and hiring 25 different human translators could take several weeks and delayed the release of a new feature.

[John_Balestrieri]

@Jeff_Tullin

(I have many customers in ‘foreign countries’ who prefer the English text even though their machines are configured for French or German

Oh, this is a good point—I’ve actually had this come up in the past: One user in Japan preferred the English-language version of my app. With Xcode’s app localization, I couldn’t offer that feature.

[John_Balestrieri]

That was quick! I put together a little module to load my Xcode string files.

I added debug logging to catch missing translations, and caught a few that are missing in my other apps!