Using a shared list of translations for XML files (tax, account), XSL transform

[pocock (Daniel Pocock)]

This is incidental to the topic about using XSL to generate tax codes. That other topic is about the repetitive patterns that appear in each VAT system. This topic is about the language of the text in tax_*.xml and account_*.xml

@dave gave the example how languages are implemented for Belgium. The problem with that solution is that each country will have to duplicate the strings. For example, the strings in the French language are much the same in all EU countries using French (France, Belgium and Luxembourg). Some of those strings are also the same for non-EU countries using French, e.g. Switzerland.

Therefore, I took a new approach:

• a single XML file with the strings, it could be shared between countries. I generate that from a spreadsheet / CSV, there is a script to convert the CSV to XML

• a base tax.xml that has XML tags for each string. It can also use placeholder arguments

• an XSL transform that merges the strings from the master list into the tax.xml

• a simple shell script that runs the XSL for each language, notice how the language code is passed on the command line

Notice that only the tax.xml is specific to account_ch. The XSL and string list could be used for any countries. I feel this is most relevant for EU countries because they all have similar intracommunity VAT rules, only the language differs from one country to the next.

[pokoli (Sergi Almacellas Abellana)]

@pocock

Some of those strings are also the same for non-EU countries using French, e.g. Switzerland.

I do not understand why a string can be the same in several languages.

Could you clarify this point?

[pocock (Daniel Pocock)]

Consider a simple example, the string “VAT” and the alternatives, “TVA”, “MwSt”, etc

Should copies of those translations be kept in every account_* module?

Or can we have a single list of these words to share between all the account_* XML files?

In the example for Belgium, the strings are stored inside the account.xml and tax.xml files. If somebody wants to use the French strings for account_ch.xml then they would have to duplicate those from account_be

[pokoli (Sergi Almacellas Abellana)]

I do not think it’s worth the effort to create a custom module to just store some common strings like VAT.

@pocock

Should copies of those translations be kept in every account_* module?

Yes, I think this is easier to maintain.

[pocock (Daniel Pocock)]

When I used grep on the tax_ch.xml file I found 160 strings. Many of them are repeated or they are combinations of other strings.

The l10nStrings.xml file is only 58 lines: that significantly reduces any effort for translation.

For somebody who only works on one country this is not a big issue.

On the other hand, to bootstrap Chart of Accounts for many more countries, transforms like this would allow us to create 50% or more of each other country very quickly. If we could bootstrap some of those into a draft or beta account_XX then other volunteers might come along and complete them.

[pokoli (Sergi Almacellas Abellana)]

@pocock

If we could bootstrap some of those into a draft or beta account_XX then other volunteers might come along and complete them.

I do not think it makes sense to have a module to just have translation of plain strings. This just increases the complexity and the maintenance cost.

For me you are overoptimitzing, we do not have so much chart of accounts and most of them are not translatable.

I will prefer if we focus on adding more chart of accounts on Tryton and latter one we can try to find a solution for translation if this is really a problem.