[Advacs-discuss] Loclisation - language and rules

[Helmut Wollmersdorfer]

Oliver Elphick schrieb:

> The German translations that Helmut sent me made me think how they will
> apply where language and country are not co-extensive.  I am trying to
> work out how to organise the project directories to handle
> localisation.  It seems to be more of a problem here, because there are
> rules of law for each country as well as language differences.  That is,
> each country has its own laws; some countries share a language (a least
> to a degree!) and some countries have multiple languages.
> 
> For example, de (the language) seems to cover Germany, Austria and parts
> of Switzerland, while Switzerland has three other languages (French,
> Italian and Romance).

Romance is less important, as it has a small population, and companies 
in this region are typically farmers, restaurants, hotels and small 
business. And they all speak German as well.

> Currently I have
> 
> sql
>  |
> +---------+
> |         |
> GL...    national
>             |
>    +--------+---------+---------+
>    |        |         |         |
>   AT       DE         GB       CH
> 
> so is that adequate?  Would you like to have:
> 
> sql
>  |
> +---------+
> |         |
> GL...    national
>             |
>    +--------+---------------+------------------------+
>    |                        |                        |
>    de                      en                        fr
>    +----+-----+         +------+------+-----+    +------+------+-----+
>    |    |     |         |      |      |     |    |      |      |     |
>    AT   DE    CH        GB     AU     US   etc   FR     CA     BE   etc
> 
> or
> 
> sql
>  |
> +---------+
> |         |
> GL...    national
>             |
>    +--------+---------+---------------+
>    |        |         |               |
>    AT       DE        GB              CH
>                       |               |
>                       +--------+      +-----+-----+-----+
>                       |        |      |     |     |     |
>                       en       cy     de    fr    it    rm
> 
> This needs to be sorted out now and it will be very awkward to change
> later.  I will need to build the include files so that they pick a
> particular language and country, and that means I need to know
> immediately how they will be organised.

_include_ Files?

Ok, if we are speaking about national _rules_ this may be the way.

In most cases - I believe - the laws of a nation are written in _one_ 
language. In Austria we have two official minorities (Slowenian 
speaking, and Burgenland-Croatian) which have the right to communicate 
with the government in their native language, but laws are written in 
german language only. Also I never heard that an AT.company uses these 
languages for accounting.

The swiss seem to have their laws in DE, FR and IT.
E.g. the tax law http://www.admin.ch/ch/d/sr/0_725_121/a8.html 
(DE-version) can be switched per click to IT or FR 
(http://www.admin.ch/ch/f/rs/0_725_121/a8.html)

Besides, I see a need, that companies want to use e.g. EN instead of the 
local language, or want to use more than one language.

This e.g. could mean for the VAT-table:

AT:
ID1 DE Normalsteuer       20.0 ...
ID1 EN normal tax         20.0 ...
ID2 DE ermäßigte Steuer   10.0 ...
ID2 EN reduced tax        10.0 ...

CH:
ID1 DE Eingangsabgaben     8.5 ...
ID1 FR Redevances d’entrée 8.5 ...
ID1 IT Tasse d’entrata     8.5 ...
ID1 EN import tax          8.5 ...

[Just an example; the swiss do not have VAT]

A table structure like this would be more appropriate:

vat.parameters
ID1 8.5 ... ...

vat.text
ID1 DE Eingangsabgaben
ID1 FR Redevances d’entrée
ID1 IT Tasse d’entrata
ID1 EN import tax

This would only need a file hierarchy like
national/
    GB
    AT
    DE
    CH

and users can add languages, if they need.

I suggest a similar principle for tables, where only one or a few 
_samples_ can be delivered per default.

Typical examples are the account plan and the structure of the balance 
sheet. They depend on size and kind of the company, and at least on 
individual needs.

In AT most of the companies will use EKR - EinheitsKontenRahmen 
(~EN:Unique Accounts Frame), select one of the variants depending on 
kind/size of company, and adopt it (create additional accounts, delete 
unneccessary) to own needs.

Same is true for the balance sheets, where the structure is nice 
standardised by the rules of local business/company law.

If someone needs to switch between languages, or create balance sheets 
(or other reports) in different languages, a translation table like this 
will do:

balance-sheet.texts
balance.position-ID language-code text
A                   DE            Aktiva
A                   EN            Assets
A.1                 DE            Anlagevermögen
A.1                 EN            fixed Assets

account-plan.texts
041                 DE            Maschinen
041                 EN            Machinery
02010               DE            Kassa Zentrale
02010               EN            Cash Headquarter
02011               DE            Spesenkassa Direktion
02011               EN            Petty Cash Directors

Hierarchy
   national/
     DE
     AT
       account-plan.data
       account-plan.texts
       account-plan.small.data
       ....
will be enough.

At installation the package should should come with defaults according 
to the usual linux/unix locales, and - maybe - automatically set up one 
example company, default language, default rules from /national.

User can custize this default company to his own needs, or discard it 
and set up a new company-instance in the way, that he chooses between 
the the possibilities under /national.

> Either way, we are likely to get a lot of duplication; perhaps it can be
> managed by symbolic links, or stub files that direct the inclusion of
> files from a different part of the hierarchy.

I dont think so.

We cannnot solve any possible variation.

I suggest a flat hierarchy of sql/national/[country-code]/

Beyond this it's a problem of company-specific configuration and 
customisation.

Helmut Wollmersdorfer