Comparison I18N

From OpenPetra Wiki
Jump to navigation Jump to search

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]).

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

Flexible Layout vs Fixed Layout

TODO

Data customizing

Culture Settings

TODO: Date format etc

Numbers and Currencies

Numbers.JPG Currency.JPG 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

Retrieved from ‘https://wiki.openpetra.org/index.php?title=Comparison_I18N&oldid=1194’