A user at my site was puzzled at the drop-down having US English and GB English, but no generic English. I experimented and as expected when I remove the 2 English lang files the site rendered properly (the native code in WT is english), but there was one oddity. Once you change to a different language there is no way to change back to English. Is this the expected behavior? Shouldn't Australian, New Zealand and Canadian English speakers (for more see
") ) who do not want US or GB versions be able to switch back to English?
Like (almost) every multi-lingual application, webtrees is written in English, and translated into other languages. In particular, it is written in a form of International English. This uses en_US spelling and grammar, but avoids any en_US terminology or idioms.
We can easily add en_NZ, en_CA and any others if anyone is willing to translate them and then maintain the translation. I thought about it for NZ, but decided it isn't worth the effort, so I use en_GB (no kiwi would ever use en_AU :-) )
en_AU does exist. It is not part of the standard set, but is available in the "Extra" languages set available at Add-ons. But even it only has a tiny number of differences, less than 5% as I recall.
If you look at the size of the en_US language file it is minute compared to all the others. This is because it IS virtually the generic webtrees language. This is why install instructions (somewhere) specify that there must always be at least one language file present, and we recommend this is en_US, so it is effectively the "English" your users want.
We supply both en_US and en_GB because there are a significant number of differences (approx 10% of translations differ), and there is no single, official "English".
The British and the Americans probably have a different view of what would constitue "generic English". We can't even agree on how to write dates ;-)
So, we use the language names as defined in the CLDR (common locale data repository) - a (de facto) international standard on locale information.
The CLDR is also the basis for our I18N library.
But, I've actually written some code that improves the handling of languages.
Our list of supported languages is getting quite large. The new code stores the language details in the database, which allows you to "untick" languages to remove them from the list. Otherwise, it is necessary to remove unwanted languages after every upgrade.
And, since it is in the database, you can rename languages.
It also makes a significant improvement to the page loading overhead. Roughly 25% of the time spent generating page headers and menus is initialising the languages. On my machine, this is about 80ms out of 320ms. This change gets rid of that.
But, like many changes I have planned, it requires a table of lookup data, and I haven't yet come up with a suitable framework for installing/maintaining tables of lookup data. I'm still working on it.....