Adding Languages to Writer's Character, Font Menu

[Richard Wordingham]

On Tue, 23 Jun 2015 21:07:12 +0000
toki <toki.kantoor at gmail.com> wrote:

> On 06/22/2015 07:30 PM, Richard Wordingham wrote:
> 
> > How do I add a language to this menu so that fonts that can will
> > render text in the style appropriate to the language? 

I've been getting a fair bit of information off list, though it's not of
immediate use to me.

Most relevantly, arbitrary recognised languages can be entered for the
Western scripts -
https://wiki.documentfoundation.org/ReleaseNotes/4.3#Adding_a_new_language_tag .
There is a bug report out for this prima facie racist behaviour - Bug
#81714: https://bugs.documentfoundation.org/show_bug.cgi?id=81714 ,
where there is a brief explanation of why the capability is so limited.

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.
* Allow arbitrary lang tags to be used in a text anywhere
* Add ability to read language support from say ldml file as
  configuration (should this go with a doc, no idea)
* Be able to associate a language with CTL/CJK.

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.

>* 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.  I believe the UNO interface supports this,
but I won't be sure until I've tried it.  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.

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

This hits the problem that ICU looks broken in this respect.  One is
meant to compile in the support languages - and the line-breaking
algorithms require human intervention, because the definitions cannot be
compiled to efficient code.

>* 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.

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.

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.  My preference would be to allow them all, but to have
a flexible method of selecting which appear in the lists.  Most people
won't use many - and a dozen or so choices of varieties of English or
French in a 1-D list is overwhelming, and two dozen choices for Arabic
is also excessive.

> 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?

Richard.