Proposed changes for this is:
http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz32853&id=46cd8b949d68c1d821ed36e27932afd2130d38b6

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?

Humm, perhaps should default to $LANG followed by $LANGUAGE.   Not respecting $LANG is definitely wrong.

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

Ok, this definitely needs more thought since language handling is such a delicate matter.  Fortunately, I guess not many people use $LANGUAGE...

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.

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.

We have the namelang object to select the language for family/style/fullname object now. so that may be time to rework on it...

reworked:
http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz32853

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.

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.

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

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

BTW do you have any pointer for that pango issue? interesting...

updated patch to drop $LANGUAGE thing.

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.

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.

Okay, merged into git master.