Can't export zh_CN file properly

I’m a localization worker try to export the zh_CN.lproj. Seems like Lingua can’t handle the character. I tried to open the .string file with VS Code, and it told me that this file is corrupted. It confirms that the information from the shows that it can’t load that .string file.

Here is the info

Error 19:05:30.913809+0800 Filmotech Unable to load .strings file: <private> / Localizable: Error Domain=NSCocoaErrorDomain Code=3840 UserInfo={NSDebugDescription=<private>, kCFPropertyListOldStyleParsingError=Error Domain=NSCocoaErrorDomain Code=3840 UserInfo={NSDebugDescription=<private>}}

The Windows version of this app simply refuses to run at all.

I copied the .string file then manually replace the translation. It worked. So I assume that this problem is caused by Lingua.

Now I try to make a script or app to generate the .string file from the tab-delimited file. But it’s still a lot of work to do.

Is there any other workaround?

Hi Oliver

You need to ask the person with the Xojo project to export the Simplified Chinese Lingua file. You can then edit the translations using the Lingua app.

I got the Lingua file with the extention name of .xojo_locale. I’ve finished the localization within Lingua. The part that bother me is export the translation to app.

You import / drag and drop the Lingua file into the Xojo project and then build your project.

I normally don’t save the Xojo project with the translations and just add them in at build time.

I’m not the owner of that Xojo project. All I can do is smash the export button… The developer of this app once sends me a copy of the .string file. I’m not sure whether it’s exported from Lingua or a build. That file is also corrupted… So if the file is from a build, then the problem may be caused by the Xojo framework itself…

I’m not really understanding your reply but I think there is a misunderstanding of how this works rather than a framework issue.

This is a summary of what we do:

  1. Our project is designed in English so the English strings are added to the project as localisable constants.

  2. When we want to localise our app we perform the following steps:
    a) Import any previously created Lingua files into the project to merge in any existing translations.

b) Use the export option within Xojo to export the Lingua files for the languages we want. This will export the strings we just imported with any new untranslated strings.
NOTE. We don’t save our project at this point (our saved project is always English only).

  1. The Lingua files are edited by the translators.

  2. When we want to create a multi-lingual build of our app we open our project in Xojo, import the Lingua files and then build. It is the Xojo compiler that generates the OS specific language files from the multi-lingual strings we have imported into our project.

How do you create the .string file? Lingua makes xojo_locale files.

I’m using Open Lingua from Thomas Tempelmann ( I’ve added Excel export so that I can do - for instance - spell checking in Excel.

In the File > Export > To Application…

Then Lingua will export the .string file to the Contents/Resources/zh_CN.lproj

And seems like the .string file is corrupted.

Sorry for my crappy English…

I’m a translator. There’s an export option in the Lingua app for translators like me to test our work without having the Xojo project. The problem now I run into is I want to test my translation but Lingua can’t generate correct zh_CN.lproj folder in the Resource folder.

I found out that the problem is caused by a corrupted Localizable.string file. Neither the app needs to translate, nor any third-party editor can read this file. So to test out exactly which part of the workflow is down, I duplicated the string file of another language, not specifically need to be English, manually change the string file, and find that the app is now localized.

Therefore I assume that this problem might be caused by the Xojo framework or Lingua app.

Lingua can only export to the application and to tab delimited:

Open Lingua can export to “Localizable.string” file, tab delimited and I added Excel:

A .strings file has a very simple format:

Do you have encodings problems? Please show us what you are doing and what you get as result.

Hi Oliver

No need to apologise. Your English is significantly better than my Chinese.

Unfortunately, it is not possible to work this way.

After you have made your changes to the Lingua file you must send it back to wherever owns the project and ask them to send you a build containing the translation.

I just confirmed that the Localizable.string file is misencoded even its extract from the build.

I accidentally found out that the Localizable.string file both from the build and Lingua app is originally UTF-8 encoded. But somehow the metadata tells that the file is UTF-16 LE, which leads to this problem… I can manually fix this problem by reopening the file with UTF-8 and save it as UTF-16 on macOS.

But this workaround is not appliable for the Windows version. The .mo file that Windows platform for localization is not a standard string file, thus it’s still won’t run.

By reviewing the hexdump of the Localizable.string, I found out that the file is misencoded both from the build and exported from Lingua…

Yet I can manully reopen and save it with correct encode. But not so lucky for the Windows verison of this localization.