Created attachment 179843 [details] Options: Date acceptance pattern still in English In LibreOffice Options, the date format is written with the abbreviate forms in English, that is D/M/Y;D/M;D.M.Y;D-M-Y. In an effort to achieve accessibility, these abbreviations should be displayed in the chosen interface language. Not everyone is familiar with foreign formats, and even less so when they are featured in a non-native language. Thank you in advance.
No, those identifiers/keywords won't be translated. The patterns follow the selected locale, not a "foreign format", but translating the identifiers would just lead to more mess. Following the Excel annoyance to have translated keywords in some locales' number format codes was already bad enough.
(In reply to Eike Rathke from comment #1) > No, those identifiers/keywords won't be translated. The patterns follow the > selected locale, not a "foreign format", but translating the identifiers > would just lead to more mess. Following the Excel annoyance to have > translated keywords in some locales' number format codes was already bad > enough. For someone who is not informed of the feedback, what are the issues that have been identified when the keywords were translated in some locales' number format codes? Is it a matter of interface consistency that could confuse users? Still, I don't think that all users understand these formats written in English. Should we exclude that the benefit of having a fully translated interface prevails over a change of practice if this is the concern?
Wrt number format codes: you simply cannot create code (in Basic) or formulas (in Calc) that would use format codes, and would work wherever they are opened. The specific codes, separators, everything there is locale-dependent - and thus, a format string created for one locale would create something absolutely wrong in another locale. Have 's = Format(x, "0,000.00")' number format for thousand separators and two decimals after decimal dot, which would work for en-US - and it will fail in locales where comma is decimal separator. Have '=TEXT(A1;"JJJJ-MM-TT")' for German locale to show ISO date format - and it will fail in France (using J for days, not using T) or in USA (not using J or T). The things here are not *words*, they are *codes*. The origin of the code is irrelevant: you do not use "YEAR", you use some character, like "Y". It's bad to have codes "translated", just to create impression of localization here - and make it all unportable, unusable. Anyone using a localization then would be unable to use an acceptance pattern they find anywhere - if it was provided for a different locale. Translation should be done only for words, not for codes.