Comparison I18N: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Introduction =  
= 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]).
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]]).


= Global Program Parameters =
= Global Program Parameters =
Line 13: Line 13:


= String Translation =  
= String Translation =  
 
* see instructions for Translators here: [[Documentation for Translators]]
== Criteria ==
* instructions for developers regarding translations are here: [[Translation documentation for Developers]]
* easy for translators (do they need the full IDE? poedit?)
== Requirements ==
* easy for translators
* easy to update translations
* easy to update translations
* easy for users to switch between UI languages; restart should be ok
* easy for users to switch between UI languages; restart should be ok
Line 53: Line 54:
TODO
TODO


= Handling of Culture Dependent Ressources =  
= Handling of Culture Dependent Resources =
 
== Dates and Times ==


== Culture Settings ==
TODO: Date format etc
TODO: Date format etc


=== Numbers and Currencies ===
== Numbers and Currencies ==


[[File:Numbers.JPG]] [[File:Currency.JPG]]
[[File:Numbers.JPG]] [[File:Currency.JPG]]
Line 82: Line 84:


First solutions
First solutions
# The notation “CHF” is actually not supported in openpetra (*)
# The notation “CHF” shall be handled as described in https://sourceforge.net/apps/mediawiki/openpetraorg/index.php?title=Multiple_Currencies#Switzerland
# 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.
# 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.
 
 
: First proposal: We have to define on own set of CultureInfo-Records to deliver it in the openpetra installation process.
: Second proposal: Open petra shall be able to handle its own CultureInfo-Records which may be additional to those of Windows.
 
I prefer the second proposal. To understand this we shall go back to the time as “Deutsche Mark” has been changed to “Euro”. The installation of an upgraded CultureInfo data is done by Microsoft by installing a service pack. This is independent of an openpetra upgrade. To be able to synchronize such things we shall override the currency symbol only.  


(*) If we use the openpetra DB-entry, we shall use it in any time. Do we want to do this? I think: No
Result: We shall use CultureInfo, add a set of parameters (e.g. the smallest currency value) and override the currency symbol.

Latest revision as of 14:45, 28 July 2016

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

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:

  1. 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.
  2. The hmi-culture always shall be a variable local to the client.

String Translation

Requirements

  • easy for translators
  • 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

Handling of Culture Dependent Resources

Dates and Times

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” shall be handled as described in https://sourceforge.net/apps/mediawiki/openpetraorg/index.php?title=Multiple_Currencies#Switzerland
  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.


First proposal: We have to define on own set of CultureInfo-Records to deliver it in the openpetra installation process.
Second proposal: Open petra shall be able to handle its own CultureInfo-Records which may be additional to those of Windows.

I prefer the second proposal. To understand this we shall go back to the time as “Deutsche Mark” has been changed to “Euro”. The installation of an upgraded CultureInfo data is done by Microsoft by installing a service pack. This is independent of an openpetra upgrade. To be able to synchronize such things we shall override the currency symbol only.

Result: We shall use CultureInfo, add a set of parameters (e.g. the smallest currency value) and override the currency symbol.