I'm using Poedit/1.8.11 on Windows 10 to manage translations for a CakePHP project, namely English and Spanish.
For each catalog, I've chosen the translation language from the drop down list so I presume they are correct:
In source *.po they look like this:
"Language: en_GB\n"
"Language: es_AR\n"
Nonetheless, spell checker is checking both translations as Spanish. The program does not seem to recognise the language and I can't find any menu item to pick it manually:
Online help does not even mention spelling. How do you set the spell checking language in Poedit?
This isn’t a programming question, but a “how to use Windows 10” one. In Windows 8+, the spellchecker always uses the language of your keyboard (which is a different thing from its layout!).
See https://superuser.com/questions/480540/how-can-i-change-the-spell-check-and-auto-correction-language-of-ie10-windows8 for detailed instructions.
As Václav Slavík explains, Poedit does not implement its own spell checking solution. Instead, it relies on Windows builtin spell checker.
In any case, Windows spell engine appears to ignore both current input language at OS level:
... and current translation language set in gettext catalogue:
Instead, it appears to merge the dictionaries of all available languages and run a simultaneous check on all of them:
I understand it's a feature aimed at mobile users since it's similar to what Android virtual keyboard does but in this particular case it renders the entire tool useless.
Given that configuring languages is particularly difficult and counter-intuitive, I recommend to just ignore the feature.
Related
I have a simple native Visual C++ program that uses .mui files to implement resource localization. If I request fr-fr in SetThreadPreferredUILanguages, Windows finds my prog.exe.mui file in the fr-fr subdirectory, and uses it fine. But if I request just fr (no locale), although Windows sees the resource file (as verified by GetFileMUIPath), it refuses to use it, and goes to the ultimate fallback language. If I request fr-ca, and only have fr available, it refuses to use it.
This happens for "es" as well, and I imagine any "neutral language". It does work for "vi", so it's not a two-letter issue, but I think that's because vi is an actual locale, not a neutral language. This happens under both Windows 7 and Windows 8.
Is there something different I'm supposed to do in preparing the .mui files, the resources, or calling SetThreadPreferredUILanguages than I do for every other 4-letter specification? This is so basic ... what am I missing??
After much painful experimentation, I have come to the conclusion that although Windows will happily accept and report on so-called neutral languages (e.g., "fr"), it does not actually look for them in that way.
If the system is running "fr-ca" but one's program only has available "fr-fr", Windows will do the smart thing and use "fr-fr". But if all it has is a "fr" folder, Windows will not use it. If one explicitly requests "fr" in SetThreadPreferredUILanguages, it will happily accept it, and happily report it back from GetThreadPreferredUILanguages. It will happily list "fr" as available from GetFileMUIPath. But it will not do anything productive with it, not even look for "fr-fr".
Simple answer: do not attempt to use "fr" or "es" or any other "language neutral" nomenclature. You must always fully specify the locale, and by unspoken agreement, things like "fr-fr" are considered neutral.
I have couple of application written in PyQt4 where I've used standard Python gettext library for internationalization and localization of GUI. It works good for me. But I've selected gettext just because I've already had knowledge and experience of gettext usage, and zero of experience with Qt4 tr() approach.
Now I'd like to better compare both approaches and understand what I'm missing by using gettext instead of QObject.tr, and does there any serious reason why I should not use gettext for Qt4/PyQt4 applications?
In my understanding advantages of using gettext are:
GNU gettext is mature and it seems to be standard de-facto in GNU/Linux world.
There is enough special editors for PO files to simplify translators work, although textual nature of PO templates makes it not strictly necessary.
There is even web services available which can be used for collaborative translations.
gettext is standard Python library, so I don't need to install anything special to use it in runtime.
It has very good support for singular/plural forms selection via ngettext().
What I see as advantages of QObject.tr():
This is native technology for Qt4/PyQt4 so maybe it will work better/faster (although I have no data to prove).
The messages to translate may have additional context information which will help translators to choose the best variants for homonym words, e.g. the english word "Letter" can be translates as "Character", "Mail" or even kind of "Paper size" depending on the actual context.
What I see as disadvantages of QObject.tr() vs gettext:
I did not found in the Qt documentation how's supported singular/plural selection there.
Qt4 TS translation template is in XML format and therefore more complex to edit without special editor (QT Linguist) and it seems there is no other third-party solutions or web services. So it would require for translators to learn new tool (if they are already familiar with PO tools).
But all the items above are not critical enough to clearly say that any tool is better of other. And I don't want to start flame war about what is better because it's very subjective. I just want to know what I missing as pros and cons of QObject.tr() vs gettext.
One simple reason to use QObject.tr() is:
It saves you the need to install gettext on Windows, making cross-platform work a bit easier.
I try to have as little binary dependencies as possible on Windows.
All have their pros and cons, but to define them more clearly you would have to define first if you're targeting a mobile environment or a desktop environment.
Within our company we use different methods simply because the ideal solution does not exist yet.
For desktop development we're using PO files simply because the buttons are not scaled and therefore text will fit.
For mobile development, the translation of a string depends on the button size which could be different on landscape and portrait devices.
So this complicates it a little because a PO file can just have 1 translation of a certain word.
So we selected XLIFF for this, so we could assign unique ID's to a string.
This is not an easy task as well, because there are no good solutions to convert .RC files to XLIFF files.
(Because current tools convert ALL strings between "" which is of course unwanted behavior).
So I wrote a converter for this task.
However, when thinking of localization, then plural forms are very important so not having this is not a good localization solution.
Therefore, I would say to go for PO gettext.
Greetings,
Floris.
At the current time, Qt does not handle plural forms when you're making use of QT_TRANSLATE_NOOP
You could add that args are managed differently...
With Gettext, we can do
_("Hello %(name)s from %(city)s") % {person.__dict__}
whereas in PyQt, we do
self.tr("Hello %1 from %2").arg(person.name).arg(person.city)
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.
my primary language is spanish, but I use all my software in english, including windows; however I'd like to use speech recognition in spanish.
Do you know if there's a way to use vista's speech recognition in other language than the primary os language?
Citation from Vista speech recognition blog:
In Windows Vista, Windows Speech
Recognition works in the current
language of the OS. That means that
in order to use another language for
speech recognition, you have to have
the appropriate language pack
installed. Language packs are
available as free downloads through
Windows Update for the Ultimate and
Enterprise versions of Vista. Once
you have the language installed,
you’ll need to change the display
language of the OS to the language you
want to use. Both of these are
options on the “Regional and Language
Options” control panel. You can look
in help for “Install a display
language” or “Change the display
language”.
To complete aku's answer, you have here different methods to have a "multilingual use in Vista".
Installing a language pack
Switching to a different language (and back)
Creating computer users. Create a user for each language and change the display language for that user to the language of your preference. A new Speech profile will be automatically created for that user. Switch between your languages by the normal procedure of “switching to another user” (Log offà Switch users).
Note: You can create a speech recognition profile for each user with any name you prefer. Change the name, or create a new user, in the Advanced Speech panel.
COMMENTS:
The advantage of the Separate Users method is that you can switch back and forth without changing any computer defaults.
The disadvantages are that it takes more disk space and more attention must be given to user management, and that you may not have access to files opened or saved by your other users unless you know how to give yourself such an access via the new permission dialogues of Windows Vista.
You should look at System.Speech.Recognition.SpeechRecognitionEngine - it's an 'in-proc' recognizer that will let you specify the language you want.
Your next problem is that en-US Vista doesn't ship with the spanish recognition engine. For that, you'll need the Spanish Language Pack. Once you install that, you should be able to instantiate a spanish recognition engine like this:
using System.Speech.Recognition;
SpeechRecognitionEngine recognizer = new SpeechRecognitionEngine(new CultureInfo("es-ES"));
At that point, you can install grammars & do recognitions, etc.
Sure, but I want to do it without
changing the display language... no
way then?
No, not officially, if you believe this KB article: The Windows Speech Recognition language must be the same as the operating system language in Windows Vista.
So try to change it automatically, there some scripts on the internet, I found them via yahoo with Windows Speech Recognition "change language".
This one looks interesting, but it is not tested. I don't know, if it's malware or whatever, so be carefull:
Vistalizator
Good luck!
You can install the language pack, but not apply it on your user. Then you might be able to change the language of the speech recognition, although I haven't tried it since I don't have Vista Ultimate.
It will work fine as I had by changing lanuguage support.