Hi Jean-Baptiste, On Friday, 2016-07-29 11:32:56 +0200, Jean-Baptiste Faure wrote:
> https://translations.documentfoundation.org/fr/libo_help/translate/swriter/01.po#unit=29751036 > > Jean-Baptiste Faure <[email protected] > > <mailto:[email protected]>> schrieb am Do., 28.07.2016, 19:01: > > > > In strings like KBqQD in the Help there is a string describing a date > > format DD/MM/YY. As it is a special tag for exporting document in html > > format, I am not sure if this string must be translated. It is > > translated in the current French Help but Pootle says there is an > > XML error. Awkward situation.. ;-) So, * the XML error probably is because <SDFIELD> is not a declared XML element, and should not because it is plain help text * as such probably the <> need to be escaped like in <SDFIELD> * the DD/MM/YY can be translated for the locales that do use the legacy translated number format code keywords, e.g. French and German * however, the actual code is tied to the two numbers preceding it, and using translated codes with the same number won't work * the original (?) English example already messed things up as it combines a German de-DE locale 1031 with English keywords and DMY order and uses the ',' comma decimal separator in the number 35843,4239988426 * the SDVAL value never uses localized separators * for English en-US that should had been SDVAL="35843.4239988426" SDNUM="1033;1033;MM/DD/YY" * for German de-DE it would be SDVAL="35843.4239988426" SDNUM="1031;1031;TT.MM.JJ" * for French fr-FR it would be SDVAL="35843.4239988426" SDNUM="1036;1036;JJ/MM/AA" Furthermore, the numbers 1031 or 1033 and the like vary with the system/office locale (first number) and the actual locale of the current field (second number), so having a German de-DE field in an otherwise English en-US locale actually is sdval="42587.5455971765" sdnum="1033;1031;TT.MM.JJ" You see, translating this is a mess ;-) I suggest to give a correct (!) English en-US example in all languages and just mention that for other locales the representation may be different. After all, it's an implementation detail of internal representation for intra-data-exchange. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
