OpenStreetMap.org Translation Fixes
Hi Firefishy,
Apologize for the delay in responding to this.
To confirm,
- You'd like to have ALL en-gb translations removed
- You'd like all translations for the following removed,
Regards,
Hi,
1. Yes ALL en-gb translations removed. en-gb is frequently wrong and en is close enough. 2. Yes both those items
Note that an exclusion of en-gb can be made project by project. You spoke about OpenStreetMap, this is something that should be decided by OSM themselves. If so , translations in the "Osm:" namespace can be disabled selectively without affecting other projects still using "/en-gb" and supporting it for specific subsets of messages (it seems that Wikipedia has specific specialisations, notably for orthographic convetions as the default is using American orthography, or because there are specific messages for users in UK , e.g. for fundraising with conversion of currencies, or some default conventions for measurements). In the content of Wikipedia articles however the rules are to be permissive on orthographic variants, and there are common templates to help display alternate mesurements (e.g. temperatures, in Celsius and Farenhieght, or road speed im mph or km/h), so that only the UI (which cannot use easily those conversion templates) can properly adpat a few messages.
There's a similar situation in French (but all communities havce decided that a single French version was sufficient, and translations are made so that they can fit well with all variants, and French is now very persmissive and open to variants in the normal language, so that they can be used interchangeably).
Another different situation exists in Chinese: the automatic conversion between simplifid nad traditional Chinese generally works well, but there's a specific Mediawiki syntax to support variants, including specific variants of Traditional Chinese for Hong Kong; however this syntax does not work for translating the UI, so the 3 variants are allowed; as well this is needed for translating projects that are not based on Mediawiki or where the MediaWiki parser is not used, e.g. in subprojects or modules actually written in Perl, Python, PHP, Java, or C/C++)
In the Mediawiki namespace (that contains hundreds of message groups), not all messages are based on the MediaWiki parser. And it's difficult to isolate these message groups; so translations are still opened but MediaWiki modules may choose to use (or not use) specific message groups using variants (idfeally we should have a way in TWN tyo track these groups, so that translators are not bored seeing so many "untranslated" messages, and don't loose time trying to "fix" them. In general, variants should be avoided as much as possible, by making base translations (in "/en") suitable worldwide.
Note also that some base translations which should be in English sometimes contain typos or bad terminology that need to be corrected, however chaing them requires also changing or reconfirming all translations. This is problematic: such fixes of typos or orthographies should not require reconfirming all translations, so translating in the "/en" locale should be permitted (and if such translation is made, this should be displayed in the translate UI each time there's a different version between the base and the "/en" fixed message, so that '/en" will provide a better hint; but without forcing all other translations to be editing or reconfirmed (so the base source of translation may still contain "errors" that should not need to be fixed when only fixing them in "/en", as if it was a variant, should be sufficient. This would limit the number of messages translations that need to be reconfirmed in ALL locales (for example is a source was changed to use "colour" instead of "color", or if a comma was added or removed before "and", these are cases where other languages are not concerned at all: enven British English has several conventions about if they prefer Oxford recommendations or not; it may be good to unify the orthography and conventions in the English locale, but this is local tuning and should not affect other languages using their own conventions about this; the same will be true about how dates are displayed, with day number before or after the month name, and year appended without a comma separator in the first case, but with a comma in the second case, usually prefered for US only, but not Canada, Britain or Ireland).
Messages that need to be really fixed in the base source are just those that are too much ambiguous or misleading: only those need then to be retranslated/reconfirmed in other languages, but minor typos fixed in English should not impact all other translations. This is not jsut a TWN problem, but a problem about how each project manages its source translations. But TWN should offer a way to mark source base messages that were reimported here for just fixing minor things. Ideally projects should be able to use fixes made directly in the "/en" variant (which should then be opened, even if we close the "/en-gb" variant). Such examples of messages include those for projects that were actualyl created by developers whose knowledge of English is insufficient (e.g. projects supported by Chinese developers, which contain frequent English typos or a strange linguistic syntax which is hard to understand even for native english speakers or for all other translators that attempt to decipher their actual meaning).
Note also that source English message do not always need to be fixed: we can add documentation about the meaning or some restrictions applied, inside the "/qqq" doc (including for adding links to specific support pages, tracked bug reports, or to external community talk pages or decisions, votes, terminologic lists, or more info), so that translators can be properly guided when they translate to other languages and so they can evaluate if these external pages need to be follwoed as well or not for other languages): the source base language is generally not sufficient and does not necessarily have to be followed too much strictly.
Closing this request... There is now an open ticket for fixing the outstanding en-GB issues: https://github.com/openstreetmap/openstreetmap-website/issues/3671