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.
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.
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.
Lightweight markup languages offer a fixed set of features. This feature set is growing, but every time I write a more complex article, I have to realize something is missing. Examples include: proper image captions, table of figures, file include, cross-references, etc. So I end up creating a tool chain around it, with a Makefile and tricky sed commands.
I typically want to insert ad-hoc markers into my text and process them later. They can be one-liners, or more complex -- and this where the whole regex approach fails. Here is a snippet of an imaginary markup.
I can generate an image from an external dot file [.myDot diag.dot The process],
and it will be included with a caption.
Or the dot source is right here [.myDotHere
foo->bar->Done;
]
I'm looking for a markup tool which can be easily extended to suite my ad-hoc needs. The options I found so far
Makefile, pre- and postprocessing with sed/perl scripts
Built in regex pre-processing in txt2tags
Pandoc parses markdown into an internal AST which can be transformed with haskell scripts
So what I'm looking for is
a language designed with customization and extensibility in mind
lightweight; no TeX/LaTeX please
not something which handles all my specific issues, but not extensible
My output is usually just html, so it doesn't have to support many targets
I created Glyph with extensibility in mind. You can create your own macros either using Glyph itself or Ruby.
Glyph aims to make publishing easier while giving all possible control to the writer, it can manage book metadata, ToC, internal links, snippets, etc. etc.
For documentation on all its features check out the Glyph book, which was created using Glyph itself.
Your "toolchain" approach is a good one - You won't IMO find a single project that will handle your specific needs, best to follow the *nix philosophy and use the best tool for the job that plugs into your open toolchain.
If macro inclusion is an issue, don't worry about solving that by your choice of markup syntax - find the right tool for that specific job and use it upstream.
The choice of markup should be IMO based on the availability of transformation tools to your desired output. IMO Pandoc is by far the most actively developed project in this space, and very flexible, especially with its scripting facility. Note it's also very well supported in GoogleGroups - John will likely respond directly and quickly to any issues you may have.
Note that Pandoc's flexibility also means your master source text isn't as "locked in", as you can easily convert for example from its extended markdown syntax to reST, if say you wanted to take advantage of Sphinx's or DocBook's capabilities. (BTW also check out AsciiDoc, which the latest Pandoc outputs - apparently a reader is also in the works)
Check out Pandoc's "extras" wiki page, I've been particularly excited by the ConTeXt filter script; I'm not sure if it'll be a good fit for you, but it includes some macro include capabilities, and IMO nothing will give you better typographical control.
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'm looking for a library that will allow me to programatically modify Excel files to add data to certain cells. My current idea is to use named ranges to determine where to insert the new data (essentially a range of 1x1), then update the named ranges to point at the data. The existing application this is going to integrate with is written entirely in C++, so I'm ideally looking for a C++ solution (hence why this thread is of limited usefulness). If all else fails, I'll go with a .NET solution if there is some way of linking it against our C++ app.
An ideal solution would be open source, but none of the ones I've seen so far (MyXls and XLSSTREAM) seem up to the challenge. I like the looks of Aspose.Cells, but it's for .NET or Java, not C++ (and costs money). I need to support all Excel formats from 97 through the present, including the XLSX and XLSB formats. Ideally, it would also support formats such as OpenOffice, and (for output) PDF and HTML.
Some use-cases I need to support:
reading and modifying any cell in the spreadsheet, including formulas
creating, reading, modifying named ranges (the ranges themselves, not just the cells)
copying formatting from a cell to a bunch of others (including conditional formatting) -- we'll use one cell as a template for all the others we fill in with data.
Any help you can give me finding an appropriate library would be great. I'd also like to hear some testimonials about the various suggestions (including the ones in my post) so I can make more informed decisions -- what's easy to use, bug-free, cheap, etc?
The safest suggestion is to just use OLE. It uses the COM, which does not require .NET at all.
http://en.wikipedia.org/wiki/OLE_Automation <--about halfway down is a C++ example.
You may have to wrap a few functionalities into functions for usability, but it's really not ugly to work with.
EDIT: Just be aware that you need a copy of Excel for it to work. Also, there's some first-party .h files that you can find specific to excel. (it's all explained in the Wikipedia article)
I don't know if this is an option for you, but the new office 2007 formats are in zipped XML format, which makes it very doable to do your own modifications. See here for the specifications.
SpreadsheetGear for .NET will handle your requirements and has an API which is very similar to Excel.
When you insert cells, your defined names (and any other formulas / charts / etc...) will automatically be fixed up to reference the new range (just as they would in Excel). So you would not need to update your defined names (although there is complete support for creating and updating defined names if that is what you want to do).
SpreadsheetGear is a .NET component, but you can build your own wrapper which is callable from C++.
You can see what our customers say and download the free, fully functional evalution here.
Have you already tried using the Excel COM interfaces? Obviously Excel needs to be install on the machine, and it's a pain to deal with...
I would argue that a .net solution with COM interop for linking into your C++ application is the best solution. In more than ten years of working with them, I've never seen a COM automation of Excel that didn't leak memory somewhere.
If you need to automate Excel, I recommend Visual Studio Tools for Office. If you don't need to automate, only modify files and those files can be in Office 2007 format, you're better off finding a library that manipulates the files directly instead of opening Excel to do it.
I ended up using Aspose.Cells as I mentioned in my original post, since it seemed like the easiest path. I'm very happy with the way it turned out, and their support is very good. I had to create a wrapper around it in C# that exported a COM interface to my C++ application.