Pros and cons of using gettext instead of QObject.tr() for localization of PyQt4 application? - internationalization

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)

Related

Find links/relationships between 2 variables/objects in the code

EDIT:
I found that doxygen can generate call graphs for classes, but I could not find any options or examples where the call(er) graph is generated for public/private members of the class(es) such as fields, methods, etc.? See the example that I provided below.
Is it possible to find links/relationships between 2 variables/objects in the code using some IDE tools and code editors, i.e. in Visual Studio, Sublime, etc.
e.g.
a=func(b,c);
w=func(a,c);
Here w and b are indirectly related to each other.
In convoluted code it is very difficult to manually find such relationships.
I understand that reflection and dynamic nature of some languages can limit such analysis.
You need to provide the language you are looking to use. If I take a guess and say C/C++ you can use CCTree and Cscope in general for this functionality. Most open source developers use Cscope extensively for this purpose.
Eclipse CDT also has call graph's. It is a bit of a pain to work outside of VisualStudio for this purpose I know. But cost is part of the reason to use open source instead.
Your best bet to cover all languages for the purpose of browsing is Exuberant Ctags. This works with a fair amount of editors and all the languages you listed. With that large a list of languages and use cases its probably worth your time to learn either vim or emacs and the integrations supported here.
For Python you can also take a look at pyscope with cscope. Another excellent alternative for Python is Rope. Rope supports finding definitions and usages as part of its standard set of tools.
Most developers do not need CCTree as browsing code bases with cscope is relatively straightforward. I have used exuberant ctags + emacs on a huge variety of language for years. It takes a touch of time to learn, but the upsides are
it's free, portable, and powerful. Another alternative to CCTree is codegraph for some of your target languages.
Found a list of tools and comparison:
https://github.com/OpenGrok/OpenGrok/wiki/Comparison-with-Similar-Tools
EDIT
possible in doxygen, but only for classes and their relationships
I found it, this is code map in VS Ultimate:
http://blogs.msdn.com/b/visualstudioalm/archive/2014/11/12/announcing-visual-studio-2015-preview-availability.aspx

Best practices for internationalization using PyQt4

I want to add multiple language support to my application which is written in Python using PyQt4. I was looking for information on how to add multiple languages and would like to see how other people do this.
Here i read:
The PyQt behaviour is unsatisfactory and may be changed in the future.
It is recommended that QCoreApplication.translate() be used in
preference to tr() (and trUtf8()). This is guaranteed to work with
current and future versions of PyQt and makes it much easier to share
message files between Python and C++ code.
In files generated by pyuic4 i see something like:
WPopupCalendar.setWindowTitle(QtGui.QApplication.translate("WPopupCalendar", "Календарь", None, QtGui.QApplication.UnicodeUTF8))
This looks too long for me. I was thinking to make my own tr helper function which somehow would automate the process.
Also i could not find articles describing a workflow and specifics for developing multilingual apps in python with pyqt4.
Would you please advice me with some good and convenient techniques on this?
Just use tr (or trUtf8) everywhere to start with. Only bother with translate when you identify code that is affected by the issue with multiple inheritance (which could easily be never).
I would suggest you have a look at Qt's i18n overview, and the Qt Linguist Manual. They are obviously both oriented towards C++ projects, but it should give you a pretty clear idea of what's required.
For a working example, you could also download the source code of the Eric Python IDE - it's written in PyQt4, and has support for a half dozen or more languages.

Best approach for building a multiplattform graphical interface for a command-line application

I developed a command line application, whose binary runs in Linux, Windows and Mac OSX. It reads some text input files, but I realize that some special users can not handle this. I would then like to build some kind of graphical interface, where the user only finds buttons and scroll bars for selecting the input parameters, a big "run" button, and then it reads the output of the program and makes some figures.
I also need that everything gets finally packed in a single file, which uses only static libraries, so the user just needs to copy the file to his/her machine and run it.
I would like to know what is the best open source and multi-platform approach to do this. 10 years ago I played a bit with something similar on DEC machines, so I guess that nowadays the situation has probably improved a bit.
P.S. For designing the graphical interface, I am looking for a graphical approach, where you add buttons, scroll bars with the mouse
P.S. 2: the interface is really simple, just need less than 10 buttons, 5 text fields and 2 scrolla bars
Thanks
For advanced UIs, I would generally recommend writing a different UI for each platform (since each platform has its human inteface guidelines). However, is this going to be a simple UI, then one of the cross-platform UIs.
You also didn't mention what language you want to use.
Lastly your "1 exe file" is a bit of a myth - it applies only to Windows. On MacOSX, we use the magic app folders, so it doesn't matter how many files comprise your app, you still get drag-n-drop installs.
Look into GTK+ which originated on Linux, or wxWidgets.
Tcl/Tk is a perfect choice. No other language provides as good of a deployment solution. You can create a virtual filesystem that has your application along with icons, sound files, etc into a single file for each platform (called a 'starpack'). You can even include binary executables and libraries, though those have to be copied to the actual filesystem at runtime to be used.
You also have the option of a two-file deployment -- a platform-specific runtime called 'tclkit', and a platform-independent application file called a 'starkit'. The one starkit will work on all platforms without recompiling, rebundling, etc. It can even have platform-specific parts built-inside and chosen at runtime.
A professional Tcl/Tk developer could do a front end to a command line program in a day without a graphical GUI design tool, easily. If you're new to tcl it will obviously take longer, but that is true of any language. The point being, Tk is remarkably easy to use and doesn't require a graphical GUI designer.
For a cross platform UI, you can use GTK (if using C) or QT (if using C++).
If you can live with a rather huge application package to deliver be sure to look at https://electronjs.org/ You can keep your functionality in your commandline apps and build a modern look and feel UI using HTML5 CSS JS and before thinking "this is ridiculous" consider that Microsoft's Visual Studio code is built on this and compared to GTK / wxWidgets you can do wonders with this. It isn't even hard to do but you either love it or hate it. I'm still undecided...

What are good options for Windows GUI toolkits for a Perl program?

I am considering doing some automation of tasks on my Windows desktop (e.g. sorting through large collections of music/text/photo files, etc...).
Seeing how my main area of developer expertise is Perl on Unix, I'd prefer to stick to Perl for coding the business logic of whatever I need done, just for the sake of development efficiency.
The question is, if I want to slap some GUI on top of the work (ala Perl::Tk on Unix), what are my GUI toolkit options and which one would you recommend using?
Please note that I'd like this question to be a good learning opportunity to other SO users, so I would welcome ANY answers even if they don't necessarily satisfy my own limitations/needs listed below, although notes elaborating on how your solution relates to these considerations would be very welcome.
My considerations are mostly driven by the fact that I want a quickly developed tool for personal use to save myself time on tasks I now do manually.
Main consideration is Perlishness of development - "Easy things should be easy and hard things should be possible" as a Perl slogan goes. Especially the first part :)
Prefer (but not insist) to be as native as possible as far as components used. E.g. rather re-use Windows' file open dialog vs. having some custom Java dialog.
I would prefer to use something that would have a small learning curve (e.g. no need to learn intricacies of OLE/COM), since the goal here is speedy development of tools I need to simplify my life as opposed to developer education which I concentrate on areas more relevant to my day job :).
But I definitely would love to get exposure to something new/cool while doing this, e.g. if some nice Monad based GUI components are suggested I'm definitely curious.
Performance matters (e.g. I may need to display a directory listing with >10000 files), but is not of paramount concern - I am a pretty good GUI designer and developer and can always architect my app and design a GUI to scale well if needed).
I would strongly prefer (though not insist on) a framework that does not force me to compile stuff. e.g. Perl libraries are more preferable to custom Java stuff I need to compile. But if the framework is perfect in all other respects, I'm open to a compiled solution (as long as it doesn't required me to purchase Visual Studio or somesuch - I want to build a Windows GUI front-end for personal use, not invest in becoming a Windows developer).
I'm pretty open and flexible outside of above constraints. Some ActivePerl/Strawberry Perl libraries, MS PowerShell based components - heck, if nothing better shows up I'll just install Apache on my PC and build a web front-end :)
With respect to "perlishness" of the interface, I'd suggest plain old Tk. Unfortunately, it looks quite antiquated and non-win32-ish.
If you want native widgets, I think your best shots are using the native Windows GUI via Win32::GUI or Wx. I have no experience with Win32::GUI, but Wx is quite nice. It does, however, have a rather steep learning curve and the interface isn't very "perlish". The C++ roots show a little bit (for better or worse).
There are a few Tk-replacements that are actually thin wrappers around Tcl/Tk (I think Tcl::Tk and Tkx). They look more modern than Perl/Tk, but I have no hands-on experience with these either. If you're developing for Windows only, have a look at ActivePerl which comes with (I think) Tkx. Their ppm4 package manager is written using it and looks pretty nice!
There are a number of options listed in perlfaq3 and some additional ones that aren't. I'm only familiar with the Tk-based ones.
Perl/Tk has the most "perlish" interface but it hasn't been updated to take advantage of tile (native/themed widget) support in the current version of Tk (and probably never will be). Tkx uses a different bridge to Tk. It allows access to everything in Tk (and it's faster, too) but the syntax is less perlish. Tkx is designed to be a thin wrapper over Tk; you have to consult the Tk documentation for most things and translate for using it from Perl. The Tcl/Tk module uses the same bridge as Tkx but supports a syntax that's mostly the same as Perl/Tk.
Whether or not you need to compile anything depends on which version of Perl you use. If you use Strawberry Perl you'll probably have to compile something no matter what toolkit you choose. ActivePerl distributions have included Tkx since sometime in the 5.8.x cycle and stopped bundling Tk as of 5.10, although it's still available via PPM. Tcl/Tk is available from CPAN but I haven't been able to get it to work with the Tk library that comes bundled with ActivePerl; you may need to install Tcl separately to use it.
Personally, I used to use Perl/Tk but now use Tkx.
While Tk and Qt are also available (more general frameworks originally intended for other languages, on which you can also use Perl), and Tk probably most popular as it's been around longest, Win32::GUI would seem to meet your requirements best. If you like WISIWYG GUI designers, you could use Loft on top of Win32::GUI, but you don't have to if you'd rather do everything programmatically.
Shameless plug - I am in the process of writing a pure Perl GUI toolkit, XUL::Gui that renders its GUI using Firefox. It allows you do anything Firefox can (XUL, HTML, JavaScript, Flash, other web tech). Firefox uses the native look and feel of the OS (or any other theme you want), and is available for most platforms.
use XUL::Gui;
display Window title=>'My Application',
Button( label=>'click me', oncommand=>sub{ shift->label = 'ouch'} );
It's currently under development, but probably stable enough to start working with. The idea is to be as simple and perlish as possible. Nearly all boilerplate is optional, with sensible defaults. For example, the Window tag is only needed because I wanted to title the window.
The module is up on CPAN. I'd encourage anyone to take a look, and send me feature requests or bug reports.
I'd just stick with Tk myself. It runs on Windows and you already know it.
I would choose GTK because because it has a study guide (at the moment I'm using Wx and there's plenty of available source code in Perl using Wx but no actual official documentation .. apart from some articles, so no book ... no official stuff) , if not Qt is an option also , and it has some proper documentation(but I haven't tried it).
Tk has very big problems and I won't use it.
As for your performance problems ... I'm pretty sure no decent application would be concerned if it's displaying 100000 or 10^100 files , since very few fit on your
screen, so you can do some clipping.
If it is just to get a simple GUI on top of your scripts then the easiest path is VB.NET (or C#). That is what I do.
With Visual Studio's designer it is just a matter of designing the form, double click on the button that will that start processing, add code to read off parameters from the GUI elements (e.g. file paths in TextBox'es) and pass the information to the script through environment variables or command line parameters.
Example from one of my applications (used by real users):
Dim inputFolder As String = txtInputDataMGFfolder.Text
Dim outputFile As String = txtOutputMGFfile.Text
Dim ws As WshShellClass = New WshShellClass
Dim objEnviron2 As IWshRuntimeLibrary.IWshEnvironment = _
ws.Environment("PROCESS")
objEnviron2.Item("INDIR") = inputFolder
objEnviron2.Item("OUTFILE") = outputFile
'It may or may not help for this: the user dialogs for selecting
'files may change the current directory and running the Perl
'script or one of the .pm files would fail.
ws.CurrentDirectory = appPath()
ws.Run("%COMSPEC% /K perl -w MultRawPrepare.pl", 1, False)
Note that use of Windows Script Host for this may not be strictly neccessary, but if it
is then this is needed:
'Requires adding reference to project:
' menu Project/Add Reference/COM/Windows Script Host Object Model
' Note: "Windows", not "Microsoft".
'
'Note: the DLL may not be registered;
' D:
' cd \WINNT\system32
' regsvr32 wshom.ocx
Imports IWshRuntimeLibrary 'For WshShellClass.
appPath() is defined as follows (and required "Imports System.Reflection" in the beginning of the VB.NET file):
Public Shared Function appPath() As String
'"[Assembly]" requires System.Reflection
Dim strAppDir As String = _
Path.GetDirectoryName( _
[Assembly].GetExecutingAssembly().GetModules(False)(0).FullyQualifiedName)
Return strAppDir
End Function 'appPath
User selection of files or folders is easy to add, but is helped by HOW-TO instructions and a little bit of boilerplate code.
The Express edition of Visual Studio for VB.NET is free.

Native Tongue as Default Language For an Application

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.

Resources