There are lots of artificial domain-specific languages - for programming, for specifying constraints, etc. People sometimes even invent their own toy languages. Once it becomes possible to specify the language of a stretch of text (bug 151290), we should make it possible to specify any language the user wishes to name - i.e. specifying an arbitrary language whose name is provided by the user.
UI-wise, we should probably not just let the user type a language in whatever combo-box we provide them with, as they are likely to mistype a common language name and get an arbitrary language instead. We should probably offer adding a new language to the set of recognized ones.
UX/Design team, what do you think? We already have "no language", and bug 160256 asks for the "undetermined" code. Seems to me like very niche use case. Maybe the programming language example talks to me the most: it could be the missing block to allow extensions to deal with "spellchecking" and syntax highlighting on code snippets.
It's not a label that you assign to some text but an identifier for a bunch of other tools. Such as spellchecker, hyphenation, text completion/replacement, literal number formats etc. It's far beyond usable and needed to offer customization on all of these options. Ultimately there is no use case that you solve. We aim to cover all ISO 639 languages, and if you introduce a new one please bring it up to this committee first :-).
(In reply to Stéphane Guillou (stragu) from comment #2) > Seems to me like very niche use case. On the contrary, it is in many senses the default use case. What we have for a default right now is often broken, in that it forces an assumption of a specific language. > We already have "no language" It is no less important to have "undetermined"/"arbitrary". > It's not a label that you assign to some text It very much is, or rather - it can and should be. > Ultimately there is no use case that you solve. The use case of telling the app/the reader what is known and not known about the language of a piece of text. That's both a use case for automated tools and for manual editing.
For 'und' see https://bugs.documentfoundation.org/show_bug.cgi?id=160256#c3 I just added. For artificial languages see https://wiki.documentfoundation.org/ReleaseNotes/7.5#Language_tags That way (just entering the language tag in the combo box field or defining it per autocorr/acor_*.dat, or spell-checkers defining language tags) _any_ valid language tag can be used. There is no need to further clutter the language listbox with predefined values almost nobody uses, unless locale data exists.
(In reply to Eyal Rozenberg from comment #4) Sorry, I messed up that reply by confusing arbitrary and undetermined. Let me take that back and reply again. (In reply to Stéphane Guillou (stragu) from comment #2) > Seems to me like very niche use case. It is a somewhat a niche case, but then - there quite a lot of highly-obscure, probably-not-spoken languages that we support. I mean, this would have wildly more usage than runic ancient Hungraian... > We already have "no language" Do we have "no language"? Where? And - it's important to have "arbitrary"; but I agree it's not as important as having "no language" or "undetermined language". > It's not a label that you assign to some text Why not? And remember, we're mostly focused on a post-151920 situation. > Ultimately there is no use case that you solve. Like with any language code, the use case is telling the app/the reader what is known and not known about the language of a piece of text. That's both a use case for automated tools and for manual editing.
(In reply to Eyal Rozenberg from comment #6) > (In reply to Stéphane Guillou (stragu) from comment #2) > > We already have "no language" > > Do we have "no language"? Where? Isn't that what "[None]" is?
(In reply to Stéphane Guillou (stragu) from comment #7) > Isn't that what "[None]" is? Now that you mentioned it, I found it... but I did not think of typing "[", I only looked for "None" or "No language". It's true that it's at the top of the list, but it's a long list and the position I am in by default is somewhere in the middle.
Again, one can enter any arbitrary syntactically valid BCP 47 language tag in the language list combobox. No matter whether that is tied to the font attribution (bug 151920), even if moved elsewhere, the functionality will persist. So what is this bug even about?
(In reply to Eike Rathke from comment #9) 1. This is not a bug, it's an enhancement request. 2. I don't know what a BCP 47 language tag is; the ask here is to be able to enter any language name, not just items available on the list.
If you don't know about language tags, at https://wiki.documentfoundation.org/ReleaseNotes/7.5#Language_tags I gave in comment 5 there are also two links to follow to learn about. Then if you know how languages can be tagged you'll probably agree that anything taking an arbitrary language name, even more one where people invented "their own toy languages", and converting it to a specific language tag will be near to impossible.