I'm starting to design an application and I'd like it to support several languages from the beginning to avoid having to change big amounts of code later on to enable multiple languages.
I've written early a C application for which the messages were in a struct so I'd have several header files with the translated strings which would be integrated into the application itself, so to add a new language I'd have to recompile.
What I'd like is to be able to have a localization system that allows me to translate the application and add new languages easily without having to recompile the application. Ideally with a pretty straightforward way of translating and testing the translation (like editing a text file and seeing the results back in the app), without having to depend on 3rd party tools for the translation.
I'm thinking about writing my own system for it, maybe based on XML for the files containing the translations for example, but I wonder if anybody has experience with this and would recommend a lightweight library that provides that I'd like (even if the translation is not so direct as editing a text file). I emphasize lightweight because I think the application itself is not going to weight more than a couple of megabytes.
It's going to be a Windows application, if that's relevant for the matter. As of now I still haven't decided on the graphic toolkit I use but it's probably that I'll use the default Windows offers without using a cross platform one (like wxWidgets, Qt, GTK+, ...). But it's not set in stone, if one offered significant advantages it'd consider it.
I am not sure how lightweight is, but qt has a good support for internationalization.
Then you can use QtLinguist to simply translate your text.
Don't invent your own system. Internationalization (i18n) and localization (l10n) are almost always covered in some existing library.
If you develop for Windows, this link, Globalizing and Localizing .NET Framework Applications, might prove useful.
Related
We have an English-only Windows C++ application based on MFC. It is still being developed, with updates being periodically sent to customers.
We now have a reseller who wants the ability to translate our application into other languages as needed. I understand the standard way of translating MFC applications is by using language-specific resource DLLs.
However, this presents a problem with updating the application. When updating the functionality, we sometimes add/change/delete GUI elements and text messages. How do we "push" these changes to people who would translate the resource DLL without them having to translate the whole DLL every time? What is the best workflow for this? Are there any tools that make developing and MAINTAINING multilanguage applications easier?
Are there any frameworks that could help? The reseller would prefer to have a simple text file with all text strings in it, so dealing with a resource DLL is already an unwanted compromise for them.
Are there any good books/articles on managing multilanguage application development/maintenance?
I never worked in a multilanguage project, so I am not sure what to look for. Thanks for any suggestions :)
Surely, you would keep your content, no matter how it is eventually deployed, in a source code control system. So you can see the adds, changes, and deletes.
Only send the translater the changes that need to be translated. Then they send the translations back to you. Then you package the translation into a deployable object (e.g. DLL).
Are there any tools that make developing and MAINTAINING multilanguage
applications easier?
Our product utilizes a large contingent of worldwide resellers, so, the product is typically translated into many languages. We do not translate the resources directly. We have established a relationship with each reseller. Those that want to translate are given an English dll and a list of what has changed from release to release. Most use a tool called VisualLocalize to localize the resources. The tool produces a localized resource dll from our English dll. That dll is then returned to us, or, packaged separately. They use this type of tool because it allows them to not only localize strings, but, also resize dialog controls if needed. Control size can be an issue depending on the language translation. For example, the size of a text string may be large enough to hold an English word, but, too small for some translated languages. While it may seem “dangerous” allowing a translator to change control sizes, we’ve had enough requests to do this that it’s now standard practice. And, if memory serves me, this particular tool can import and export other files types which would potentially be of use in your particular case.
It's finally (after years of postponing) the time to localize my app in a few other languages other than English.
The first challenge is to design the integration into my C++ / MFC application that has dozens of dialogs and countless strings. I came across two possible alternative implementations:
Compile and deploy localized resource files as DLLs
Extract and replace all strings with the localized version. For each
language there will be an XML (or simple text) file.
Personally I opt for the second alternative since it seems to me more flexible. The changes are many but not hard to make, and very importantly the XML files will be very easy to modify for the translators.
Any advise is greatly appreciated.
Regards,
Cosmin Unguru
http://www.batchphoto.com/
I did some long-living MFC projects with different languages.
I strongly recommend the first approach with resource-only DLLs.
The reasons:
(1) If the user does a XCOPY install, he always has the default language (English) in the main executables.
(2) If you don't translate everything (e.g. you're late with your release or forget some strings), the Windows resource functions if properly used return the resource in the default language automatically - you don't have to implement it on your own.
(3) My very person opinion: (a) Line breaks, tabs, whitespaces in XML files are a pain in your a**. (b) Merging XML files is even worse...
(4) Don't forget the encoding. It's okay in XML but your translators might use an unsuitable editor and damage the file.
And now for the main reason:
(5) You will have to rearrange many of your dialogs, because many strings are longer in e.g. French or German than in English. And making all statics, buttons, ... larger "just in case" looks crappy.
Another hint: Spend some bucks and buy one of the translation tools which import your projects / binaries and build up a translation database. This will be amortized after the first release.
Another hint (2): If possible make a release which doesn't contain any changes but only the multi-language feature. Also in future, if possible: Release your product in English. Then do the translation in one single step (per language) and release the other languages.
My good and friendly suggestion from somebody who worked a lot with localization:
Grab GNU Gettext,
Mark all your strings as _("English").
Extract all strings using gettext tool xgettext and compile dictionalries
Translate string using great tools like poedit.
Use gettext in your project and make your localization life simpler!
You can also use boost::locale for same purpose - it uses GNU Gettext dictionaries and approach but provides different and more powerful runtime and for windows developer it has very good addon - it supports wide strings that MFC requires to use for normal Unicode support.
Don't use resources and other "translation" tools that are total crap from linguistic point of view (and developer's point of view as well).
Further reading: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html
Using a DLL resource library is a relatively straightforward operation, and allows you to manage not only strings, but other resources as well. And this is its main advantage, because i18n is not only about string translation.
However, depending on your needs, a text-based solution may be a better decision, because of its easier handling - resource scripts being more complex than xml files, especially for the average translator.
I would suggest creating your own abstraction layer, something like "LoadLocalizedString", etc.; in this way, you can start implementing it just with text files, and then change to something more complex when and if required in a transparent way - all the effort for making your software i18n aware would still be valid.
In our case we had diffrent dialogues per Language. The resource file was the same as the multiple laguages were implemented at development time. You could basically append on existing resource files the diferent languages. I hope it helps to find your way.
The DLL option is commonly used for this since the resource loading procedure (e.g. LoadLibrary) is already written - meaning you don't have to write any parsing/loading code. While XML is easier to edit, DLLs have a bit more security (users won't be able to easily edit them) and will allow the developer (meaning you) more time to work on application logic instead of writing a language loading system.
HMODULE hLangDLL = LoadLibrary("text_en.dll");
// more stuff
TCHAR mybuffer[1024] = {0};
LoadString(hLangDLL, IDS_MYSTRING, mybuffer, 1023);
If it is just the strings that are changing then I agree that XML is the way forward here for the exact reasons you outline. Easy for other people to edit, easy to change language at runtime, etc.
The only reason (in my eyes) that you'd choose option 1 is if things other than strings are being localized such as needing different icons.
If it's just text? I say go with the XML.
I'm trying to develop an ebook reader(for mobile devices) which is platform independent. Currently my focus is epub only.
As a proof of concept, we were able to make a basic epub reader for android platform, using the functionalities provided by the platform itself(using webview, Xml Parser, Unzipper etc). But now we want to make it platform independent and we want to do it in C/C++. I know we have unzippers and xml parsers in C/C++, its the rendering part I'm worried about. My questions are...
1.How can I do the rendering, without using any of the inbuilt android views, so that it will work on other platforms also?
2.Is it better to stick to webkit for epub(the platforms which we're considering all have webkit)?
As of now I'm clueless. Any pointers on where to start?
BR,
Rajeev
Most likely you will have to split your application into the cross-platform backend and a platform specific front-end.
If you want to implement indexing and searching of all e-pubs in your app, this could be part of the cross-platform part. If the epub reader contains a catalogue of downloaded/transferred epubs, the database including its access methods could probably be cross-platform as well (at least partially).
However, the presentation layer, i.e., the user interface, will probably have to be platform-specific. The best case scenario is that you can come up with an intermediate UI description language that can be automatically translated into Android / iPhone user interfaces. That is a daunting task however, and it's probably not even worth trying if you don't want to create many cross-platform apps.
The only C/C++ development environment i found was MoSync.
We are developing a rather large project in C++, where many components require configuration parameters. We would like to use a central place to configure everything (like a registry), preferably with a nice and simple GUI (e.g. like Firefox's about:config) and a simple API.
I am pretty sure this that many applications have this kind of problem, but could not find any libraries available that can be readily used for this. Does anyone know of a good (preferably free) library to use for this?
This should work cross platform in Windows and Linux.
boost::program_options provides unified (and cross platform) support for configuration from command line, environment variables and configuration files. It seems like it ought to scale to multiple bits of a large software system registering an interest in various parameters (e.g option groups). Not much help with the GUI or persistence side of things though (but then what's wrong with editing a config file with a text editor ?).
I've used libconfig before, works well easy and LGPL.
http://www.hyperrealm.com/libconfig/
I've used a modified version of John Torjo code from TechRepublic/DDJ (source)
The multi platform ACE library has a configuration class that uses config files that have the Windows .ini format.
I've often used a simple wrapper around pugxml. I find that creating a configuration class with parameter validation for enumerated types and so on makes the rest of the code much cleaner. If you are just dealing with key/value pairs you will have to validate the data all throughout your code. By writing a custom class for each application you can put all that in one place.
Try Configurator. There is no GUI, but it's easy-to-use and flexible C++ library for configuration file parsing (from simplest INI to complex files with arbitrary nesting and semantic checking). Header-only and cross-platform. Uses Boost C++ libraries.
See: http://opensource.dshevchenko.biz/configurator
I have a large MFC C++ application that I would be very keen to port into AutoCAD and IntelliCAD. AutoDesk offer Object ARX for this purpose, which replaces the older and slower ADS technology. IntelliCAD, afaik only supports ADS. Has anyone out there done this, and if so which tools did you use and what pitfalls did you encounter?
I'm specifically interested in resources that will simplify the transition, and allow me to maintain seperate CAD based and standalone versions going forward.
Have a look at my answers to a couple of previous AutoCAD questions
Open source cad drawing (dwg) library in C#
.Net CAD component that can read/write dxf/ dwg files
If you were looking for the same code base to work both inside and outside of AutoCAD then the RealDWG approach may work for you since the code is the same - RealDWG doesn't need AutoCAD as a host application. The open Design Alliance libraries are for making stand-alone applications. Both have supported C++ for years & can be considered stable - well, as stable as CAD gets.
This blog (http://through-the-interface.typepad.com/) is a good one for RealDWG
One option to consider is to target AutoCAD and Bricscad. Supporting AutoCAD and IntelliCAD requires essentially two versions of code. Bricscad's goal is to be completely compatible with ObjectARX, and in my experience they are pretty close.
This at least simplifies the problem from supporting three instances (your standalone version, AutoCAD, and IntelliCAD) to supporting two instances (your standalone version and AutoCAD/Bricscad).
"DWGdirect is not just a SDK to read and write DWG files. It actually offers a full blown framework that can be used to develop a professional CAD application, complete with plug-in architecture and all." quote source