[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreoffice-l10n] date format strings en special tags: translatable or not?


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 <jbfaure@libreoffice.org
> > <mailto:jbfaure@libreoffice.org>> 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 &lt;SDFIELD&gt;
* 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: l10n+unsubscribe@global.libreoffice.org
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

Follow-Ups:
Re: [libreoffice-l10n] date format strings en special tags: translatable or not?Jean-Baptiste Faure <jbfaure@libreoffice.org>
References:
[libreoffice-l10n] date format strings en special tags: translatable or not?Jean-Baptiste Faure <jbfaure@libreoffice.org>
Re: [libreoffice-l10n] date format strings en special tags: translatable or not?Christian Lohmaier <lohmaier+ooofuture@googlemail.com>
Re: [libreoffice-l10n] date format strings en special tags: translatable or not?Jean-Baptiste Faure <jbfaure@libreoffice.org>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.