Comparison I18N

Introduction

Two points are important during an I18n-process. First all human readable strings which shall be placed to a gui or a report shall be translated. So the developer has to distinguish between strings which are for internal use (read by software) or by external use (read by human). Strings which are used for both are not allowed. They have to be joined to a class, so that one part can be translated and the other must not be translated. Second there are language or better culture dependent settings specifying how a number, a currency and a shall be printed (See [Comparison_I18N#Culture_Settings Culture Settings]).

Global Program Parameters

There are two different types of an Openpetra installation. The first one is a typical office installation which means that one server provides n clients and the will all handle the same account. The other one is multi-client capable and this means that different users are handling different account staff contents. In order to produce the same results, by managing the same stuff there shall be a variable which handles the “report-file-culture”. That means that in a French office a balance sheet always shall be printed in French. In order to avoid any conflicts, typical servers in France are the English versions of the Windows software and the Culture Information of the server is irrelevant. On the other side a Russian guest may prefer a Russian user interface. And this shall be handled in a variable named hmi-culture.

Therefore: In office installation environments, the report-file-culture shall be a variable stored on the server and in multi clients environments the it shall be installed on the client and shall be messaged to the server. The hmi-culture always shall be a variable local to the client.

String Translation

Criteria

• easy for translators (do they need the full IDE? poedit?)
• easy to update translations
• easy for users to switch between UI languages; restart should be ok
• GUI size changes (some languages need more space)
• support asian languages
• not only language, but also culture settings

Winforms resources

• Example: SharpDevelop uses resource files
  • http://www.computer-books.us/csharp_3.php free book: Dissecting a C# Application - Inside SharpDevelop, Chapter 7, Internationalization (link at http://www.icsharpcode.net/OpenSource/SD/InsideSharpDevelop.aspx does not work)
  • Accessing Resources: centralized vs decentralized resource management model (PDF page 190)
  • online: they have an online translation application; it is proprietary (PDF page 194); offline: download xml file, translate, upload
  • not sure what they do about different sizes of controls; but it does resize somehow; even possible to switch language at runtime
• http://www.codeproject.com/KB/dotnet/Localization.aspx describes 2 approaches with resource files:
  • Creating a satellite assembly for culture specific resource file and using it in the executing assembly
  • Creating a file based resource manager which enables accessing and reading a resource file from a location outside the assembly manifest

gettext

• http://lukeplant.me.uk/articles.php?id=6 Internationalisation - Open Source vs Microsoft
  • compares gettext (po files) vs Microsoft resources, also mentions problem with missing layout managers
• MonoDevelop uses gettext: http://monodevelop.com/index.php?title=Developers/Articles/Translations
  • http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/src/addins/MonoDevelop.Gettext/
  • they are using GTK and therefore the position/size of controls can automatically adjust to different string lengths?
  • poedit on Linux has a parser for C#: easy update of new strings
• GNU Gettext for C#: http://www.gnu.org/software/hello/manual/gettext/C_0023.html
  • generating resource files, using either dlls or resources files; can add after compilation

• Mono sample for gettext: http://mono-project.com/I18N_with_Mono.Unix and http://mono-project.com/I18nGettext
  • recommended Mono.Unix; for GUI: GTK
  • on Windows
    • can use Mono.Posix.dll from C:\Program Files\Mono-2.4\lib\mono\2.0
    • can use xgettext from PoEdit for Windows
    • can use programs in C:\Programme\Mono-2.4\lib\gettext, eg msgfmt.net.exe
    • see ICT\Testing\Common\I18N

Flexible Layout vs Fixed Layout

TODO

Handling of Culture Dependent Ressources

Culture Settings

TODO: Date format etc

Numbers and Currencies

See: MSDN NumberFormatInfo

In order to run a proper I18n we shall have a short look onto the APIs already implemented in .net. Therefore you shall have a look onto the parameter settings which are available referring the MSDN System.Globalization Namespace.

A complete record of properties for the numbers, the currencies, the times and the dates, is called a CultureInfo-Class. Of course if you only want to get access to a number a NumberFormatInfo-Class will work too, but a proper I18n contains two steps. NumberFormatInfo only knows a constructor without any parameters, which means that this class constructed in this way only can get access to the locale system settings. But CultureInfo enables to select a special “LCID” or a value of a MSDN Locale Charts. This values are a concrete realization of the RFC 4646 and a best practice concept to handle those problems.

Let us have a look to an specific example. The string “String strExample = "For this object you have to pay {0} until tomorrow."” contains a variable which shall be replaced by the a value “decimalValue = 1.23456m”. This can be done with a StringBuilder-Class “stringBuilder.AppendFormat(strExample, decimalValue.ToString("C"))”. If you run this code on a PC handling the US-American local settings, you will have the result “For this object you have to pay ($1.23) until tomorrow.”. You should know that negative currency values are written in brackets in the United states. In England the result will be “For this object you have to pay -£1.23 until tomorrow.”

Problems are:

1. The language and the settings of the operating system are not necessarily the language of the user.
2. The CultureInfoRecord is not complete. For example there exists a smallest value of the currency in any currency of the world. This value actually is not provided by this record and therefore Openpetra shall provide it.
3. The CultureInfoRecord is something restrictive. All the three entries for Switzerland de-ch, fr-ch and it-ch bring out the currency as “Fr. …” and not as CHF. But for example in Germany we shall say (Without German translation) “For this object you have to pay -1.23 CHF until tomorrow.”
4. The proper choice of the CultureInfo-Settings shall be made either unique for a complete office (German Gruppenrichtlinien) or shall be handled by openpetra itself in order to avoid some conflicts.
5. CultureInfo only handles the properties inside a specific language. The negative Dollar values for example are brought out correctly for the united states but in Germany we shall write “For this object you have to pay -1.23 $ until tomorrow.”

Consequences:

1. OpenPetra shall handle a subset of the LCID-references MSDN LCID-references and the decimal values seems to be the best choice. This only works using CultureInfo classes.
2. OpenPetra shall provide some more parameters to handle "the rest" of the I18n-Problems.

First solutions

1. The notation “CHF” is actually not supported in openpetra (*)
2. In order to translate currency values i.E. to print a Dollar value in a German document a German CultureInfo class has to be created and the Currency sign of a US-American CultureInfo class has to be copied from the US-American to the German one.

(*) If we use the openpetra DB-entry, we shall use it in any time. Do we want to do this? I think: No