Re: Adding Languages to Writer's Character, Font Menu

Hi Richard,

On Wednesday, 2015-06-24 08:32:42 +0100, Richard Wordingham wrote:

> It's been claimed that this is the tip of a big iceberg:
>
> "The ideal would be to allow the following capabilities:
>
> * Tag text according to its language tag rather than using an LCID,
>   given even windows uses langtags now.

That doesn't really matter, the LCID is used internally as an attribute,
for user-added language tags we just generate an LCID on the fly.

> * Allow arbitrary lang tags to be used in a text anywhere

Already implemented, but as said in the previous mail, not yet
implemented for CTL and CJK.

> * Add ability to read language support from say ldml file as
>   configuration (should this go with a doc, no idea)

Alas, they are not a full replacement, let alone a 1:1 mapping, for the
locale data we use. On the other hand they provide more information than
what is currently in our locale data. On the long term being able to
pull in some LDML via ICU, or additionally to our locale data use
existing ICU definitions when available, is certainly a worthwhile goal.

> * Be able to associate a language with CTL/CJK.

Agreed.

> Each of these points are huge undertakings (well in pairs perhaps),
> which would take considerable community political will to see happen.
> But as a wise man once said: a single minority language has virtually
> no cost benefit, but 2000 languages changes the equation considerably."
>
> I presume LibreOffice is intended to support OpenDocument.  On this
> basis, I would say: 
>
> > * Tag text according to its language tag rather than using an LCID,
> >  given even windows uses langtags now.
>
> OpenDocument does this.

LibreOffice of course does as well. Please do not mix internal LCID use
with language tags as written to / read from ODF.

> > * Allow arbitrary lang tags to be used in a text anywhere
>
> OpenDocument allows these - it is just a question of how much
> LibreOffice supports this.

It does.

> I believe the UNO interface supports this,
> but I won't be sure until I've tried it.

Simply in a css::lang::Locale set the Language field to "qlt" and in the
Variant have the language tag, see
http://api.libreoffice.org/docs/idl/ref/structcom_1_1sun_1_1star_1_1lang_1_1Locale.html

> One problem is that
> OpenDocument depends on an undefined split of text into Western, CTL
> and CJK text - a useful trick but a bad design.

Thankfully that design award goes to MS.


> > * Be able to associate a language with CTL/CJK.
>
> This is impossible for a few languages.  Several languages exist in
> competing scripts of different categories - Sanskrit and Pali may be
> written in the Latin script as well as in Indic scripts, and I think
> Sanskrit is also available in CJK.  Several languages are used in both
> the Latin script and in the national CTL script or in the Arabic script.

Then you will have different language tags that include the script, and
have one associated with "Western" and one with CTL. I don't see the
problem.

> However, why is this association necessary?  In the bug report, Eike
> Rathke wrote, "The existing predefined CTL/CJK tags respectively their
> corresponding LCID values occur in various switch cases to be acted
> differently upon."  This needs further elucidiation.  It's not obvious
> why mistagging is to be preferred.

I just stated the status quo. I didn't say it would have to be preferred
over better solutions.

> To return to Jonathon (= Toki)'s advice:
>
> > My recommendation is that you file an RFE for each language and locale
> > that you'd like to use in LibO.
>
> With something like 2000 languages, the pick lists will be
> overwhelmed.

Agreed.

> > Whilst one can fake it, by using a different language/locale with
> > similar characteristics, that doesn't help, if one wants to do spell
> > checking and grammar checking in your documents of those specific
> > languages.
>
> I'm surprised at the central control of these, especially at the
> experimental level.  Is one really meant to mislabel text while
> developing and testing such tools?

It can be a workaround of limited use. Nothing else the paragraph you
cited suggested.

  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

Attachment: pgp8HnJC9iiXW.pgp
Description: PGP signature