I have a cross platform app (Win and Mac) using C++. I want this app to be localized for both platforms to support few languages like German, French, etc., I am looking for a common approach to support for both platforms otherwise I have to go with platform specific localization. That will double the work.
Platform specific:
Use Localizable.strings file for Mac
User .xml file keeping it in resources for Win
I am looking for a common solution to support both platforms.
You could parse the related localization files into a const list of key-value tables on startup where each list would correspond to a language and each table in the list would contain localized strings for the specific language. Then reference the strings with keys from your code.
Related
For the app I am working on I want to give the user the ability to select a different language than their phone is set to.
I have set everything up according to: https://www.c-sharpcorner.com/article/multilingual-implementation-using-xamarin-forms/ and it works great for 'official' languages like French, English, Indonesian, etc. However, since the app is pretty much about any and all spoken (or signed) language, I also want to offer the option to select Klingon, Toki pona, Esperanto, Ido, etc.
When I try to set the language to Esperanto with
CultureInfo language = new CultureInfo("eo");
the app crashes with:
Message (System.Globalization.CultureNotFoundException) "Culture name eo is not supported.\nParameter name: name" string
I have all the strings in resource files, I know exactly what the name of the file is for each language, and I don't need full localisation for these languages, so a way to force the use of 'AppResources.eo.resx' through code (after checking if the user has indeed set this preference) would also work.
Does anyone have ideas on how to do this? I feel like I'm missing something really obvious…
In case it matters, I have:
Visual Studio Community 2019 for Mac
Version 8.10.8 (build 0)
Mac OS X 10.16.0
I have and XCode project with a list of supported languages. By default, XCode only lists 4 default languages when you click on "Add Localization" on the Localized Group info window. I just followed a sample project and added Localizations in a mix of full language names and some using the what I think is ISO 639-1 notation. What is weird is this:
I added a localization name "zh_CN" (just imitated the existing project) for Simplified Chinese. When the project is compiled, it has the .app/Contents/Resources/zh_CN.lproj/Localizable.strings. I change the system's language to Simiplified Chinese and run the app. Voila, it works and gets the Simplified Chinese Localizable.strings.
However, if I use NSLocale's API, I get "zh-Hans". "zh_CN" strings were loaded yet NSLocale returns "zh-Hans".
How does the Mac OS determine to use the "zh_CN" strings when using Simplified Chinese as the locale? Is there an API to know that the current system language will use the "zh_CN"?
zh_CN is a old way to indicate Simiplified Chinese.
and now it's better to use "zh-Hans" instead. (in order to support old vernon of iOS and OSX, I think Apple will still support old style names like zh_cn.
(this document "Language and Locale Designations" explains everything :D)
Is it possible to embed a TTF or OTF font file in a C++ application so that application can use it without installing it on target machine? Any thoughts are welcome. (target platforms are going to be Windows and Macintosh). Purpose: Font is a private one and should not be available to the users.
OS X: Include the font in the app’s Resources directory, then add the value ATSApplicationFontsPath to the app’s Info.plist containing the path relative to the Resources directory.
Windows: MSDN has an article for Windows Forms using the System.Drawing.Text.PrivateFontCollection class and one for WPF using the System.Windows.Media.FontFamily class. This is assuming you’re using C++/CLI and the .NET GUI frameworks; it probably won’t apply for MFC.
Recently, got to know that a TTF font is simply a byte array. Just take a hexdump and prepare the byte array (taking care of the endianness, most modern architectures are little endian).
Following thread has details:
https://twitter.com/awmanoj/status/1071718063647580161
In golang, there is also a generator of the byte array. Quite trivial to implement the same in another language like Java/C++ per the need.
OK, so we're writing our MFC application to make use of the built-in localization support with satellite DLL's since MFC 7. Everything seem to be working fine, except that my Windows 7 Enterprise Edition install with MUI support and using a Swedish UI instead of an English UI still displays the English UI in our application.
The application uses Swedish as its default language, with an English localization DLL in the form AppNameENU.dll, so MFC is actually intentionally switching to English language under these circumstances, as if it's not caring for the user choice in the MUI-enabled Windows OS, and only the default shipping language of the Windows install?
From the MSDN page on this (the link above), I read it as MFC should actually take these settings into account though, but I'm not 100% sure. Can someone please clarify?
It's because the MFC support for language selection has a design bug: It will decide to load resources from the exe only if no DLL match user OR system language.
In your case: It sets up its (ordered) list of languages as such:
Swedish (User language)
English (System language)
Then it looks up your DLLs (Bug: only the dlls, not the exe!): No match for Swedish. But there's a match for English!
Solution: Use my CLanguageSupport class. It works fine even in your use case.
Feel free to use it. You'll need only a couple of minutes to incorporate it into your app and it uses the exact same DLL scheme as the one you already implemented. (Hint: Don't forget the step where you must get rid of the CWinApp::InitInstance() call!)
In addition, if you are interested (this is optional), you can get an automatic languages menu to let user pick his own preference in case the default is not what he wants.
And if you're looking for a great tool to help you manage your translations, think appTranslator ;-)
HTH,
When downloading both Firefox and Chrome, I've noticed that the default version I got was in my native tongue of Hebrew. I personally don't like my applications in Hebrew, since I'm used to the English UI conventions embedded in me since long ago by:
The lack of choice: Most programs don't offer interfaces in multiple languages and when they do, those languages are usually English and the developer's native tongue.
Programming languages which are almost completely bound to the English language.
My question then is this:
If you translate your applications, would you limit the UI to the user's native tongue or give them the choice by enabling more than one language pack by default?
Which language would your application default to (which is interesting mostly if you only install one language pack with your application)?
And also generally I'd like to know how much value do you put into translating your applications on a whole.
I've helped develop an application that was used by Dutch, English, Spanish and Portuguese speaking users. Because the application installed from CD we just added all the language packs. Mostly because it saved us a lot of work not having to maintain 4 different versions.
If your application distributed from a website and you have to support more than only 4 languages I can imagine you don't want to let everyone download every language pack. But only distributing the native languages of people downloading the application seems a bit restrictive. Most people I know actually like their software in english. So at least adding the english language to all the versions makes sense.
I've never written an application for use by a large number of people, and never for anyone that didn't use English as their language, but if I did, I would probably take a route that installs all available language packs at install (unless the user did a custom install, where I would allow them to choose language packs) and then switch between languages as an option inside the program. If I had to only choose one language, I would choose English if I was doing all of the work, or the native language of the users if I had a translator.
When writing an application for multilingual use, I use Microsoft's Best Practices for Developing World-Ready Applications, which includes retrieving the current CultureInfo from the OS and using that as the default language pack.
I usually try to ship products with all available sets of localized resources. Upon a user's first launch of the product, the UI is presented in the localization most closely matching the OS on their machine. Once within the app, the user has the option of switching the UI to one of the other available localizations.
I think it is very important to provide localizations that match one's target markets. Most "normal" people (not software developers!) prefer by far to have a UI in their native language.