Bug 32853 - Export API to get the default language
Summary: Export API to get the default language
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.7
Hardware: Other All
: medium enhancement
Assignee: Akira TAGOH
QA Contact: Behdad Esfahbod
Depends on:
Blocks: 29312
  Show dependency treegraph
Reported: 2011-01-05 10:59 UTC by Behdad Esfahbod
Modified: 2012-06-08 00:07 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Description Behdad Esfahbod 2011-01-05 10:59:44 UTC
Perhaps as FcLangGetDefault().  Or maybe a list ($LANGUAGE)?
Comment 2 Behdad Esfahbod 2011-06-17 15:24:56 UTC
I like this.  Not sure about the names.  In fontconfig there's precedence for names like FcGetDefaultLang() as opposed to FcLangGetDefault().

As for the $LANGUAGE accessor, I like having it at the fontconfig level, but I think if we're adding it we should also add support for it to the library.  As in, FC_LANG should default to the whole list as opposed to the single DefaultLang() one.  What do you think?
Comment 3 Behdad Esfahbod 2011-06-17 15:25:35 UTC
Humm, perhaps should default to $LANG followed by $LANGUAGE.   Not respecting $LANG is definitely wrong.
Comment 4 Akira TAGOH 2011-06-19 21:58:15 UTC
(In reply to comment #3)
> Humm, perhaps should default to $LANG followed by $LANGUAGE.   Not respecting
> $LANG is definitely wrong.

I was thinking of that though, locale related envvar is a bit complicated and how applications takes care of $LANGUAGE depends on their behavior. I couldn't figure out if one sets to LANG=ja and LANGUAGE=en:ja, returning a list of ja:en(:ja) is really expected thing for them.

So having FC_* for similar purpose in fontconfig sounds not so bad to me, and to simplify it, that would be good to allow having multiple values in it like FC_LANG=en:ja say.
Of course falling back to $LANG as usual if it's not available.
Comment 5 Behdad Esfahbod 2011-06-20 09:37:15 UTC
Ok, this definitely needs more thought since language handling is such a delicate matter.  Fortunately, I guess not many people use $LANGUAGE...
Comment 6 Akira TAGOH 2011-09-02 00:13:56 UTC
I'm pondering to stop exporting FcLangGetDefault() in my previous patch and export the list of the language only. that wouldn't makes too much problems since it's not a public API so far. given that one has FC_LANG to expect different behavior, if we have different APIs for resulting the single language and the multiple languages, whether one gets the expected behavior will really depends on which API the applications use. so I would like to avoid that situation.
Comment 7 Akira TAGOH 2012-02-10 04:13:07 UTC
just a note to keep it in mind:

A possibly situation that FC_LANG may helps is the case that one wants to obtain the family name in English or so regardless of current locale. currently, if available, what the language is used for the family name and the style name etc depends on FcGetDefaultLang() that determine the default language against current locale. there are no APIs to change this behavior unless one changes the current locale.
Comment 8 Akira TAGOH 2012-03-29 00:51:05 UTC
We have the namelang object to select the language for family/style/fullname object now. so that may be time to rework on it...
Comment 9 Akira TAGOH 2012-03-29 04:34:48 UTC

For the function name, we should rename it to FcGetDefaultLangList() perhaps.

I'm wondering if we should apply FC_LANG (at least) to the pattern prior to do FcFontMatch() when the pattern doesn't contain any lang objects. so it can gives priority. that would helps for the case of "fc-match v.s. fc-match :lang=xx" and "Chinese v.s. Japanese on non-rich text" hopefully.
Comment 10 Akira TAGOH 2012-04-25 02:31:35 UTC
Hmm, according to the naming rule in fontconfig, it would rather be FcGetDefaultLangs() since it returns FcStrSet *. I'm concerned it may confuse with FcGetDefaultLang() though.
Comment 11 Behdad Esfahbod 2012-04-25 17:50:58 UTC
I'm still concerned about letting $LANGUAGE override $LANG.  That's just not common in Linux.  Now, we're inconsistent about that in Pango itself too, so I'm not sure...
Comment 12 Akira TAGOH 2012-04-25 18:58:39 UTC
(In reply to comment #11)
> I'm still concerned about letting $LANGUAGE override $LANG.  That's just not
> common in Linux.  Now, we're inconsistent about that in Pango itself too, so
> I'm not sure...

Well, according to the man pages, $LANGUAGE should be used for alternatives of LC_MESSAGES only AFAIK. I think it may be better not relying on unsure env var on its behavior. also since there are the use case that one uses their language on English locale, it may be also better not using $LANGUAGE in fontconfig because of the above reason. this is why we are about to have FC_LANG instead.
Comment 13 Akira TAGOH 2012-04-25 18:59:39 UTC
BTW do you have any pointer for that pango issue? interesting...
Comment 14 Akira TAGOH 2012-04-25 19:03:27 UTC
updated patch to drop $LANGUAGE thing.
Comment 15 Akira TAGOH 2012-05-10 04:25:09 UTC
Behdad, do you have any concerns on current patch? the summary is:

 * export FcStrSet *FcGetDefaultLangs()
 * FC_LANG env var to be affected to it
 * normalize the language to what fontconfig recognize as much as possible
   e.g. giving FC_LANG=ja-jp will adds ja to FcStrSet*. but FC_LANG=ll-cc still keeps it as is.
 * FcGetDefaultLang() returns a first value of the result of FcGetDefaultLangs() now.
Comment 16 Akira TAGOH 2012-05-16 19:37:21 UTC
One concern on my patch is, to call FcLangNormalize() when adding langs from env var. it may be overkill. but I'm not quite sure what's advantage to keep the "language-territory" format from the locale as is regardless of fontconfig recognizes. what it works properly really depends on what configurations the users has.

I don't care if it's done intentionally like explicitly writing so in the configurations and/or giving it in the FcPattern outside fontconfig. otherwise I think it would be a good idea to do so.
Comment 17 Akira TAGOH 2012-06-08 00:07:34 UTC
Okay, merged into git master.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.