Comparison I18N
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
Culture Settings
TODO: Date format etc
Numbers and Currencies
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:
- The language and the settings of the operating system are not necessarily the language of the user.
- 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.
- 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.”
- 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.
- 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:
- OpenPetra shall handle a subset of the LCID-references MSDN LCID-references and the decimal values seems to be the best choice.
- OpenPetra shall provide some more parameters to handle all I18n-Problems.
First solutions
- The notation “CHF” is actually not supported in openpetra
- 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.