search locale name variants for gettext translations
authorRich Felker <dalias@aerifal.cx>
Tue, 21 Mar 2017 12:59:48 +0000 (08:59 -0400)
committerRich Felker <dalias@aerifal.cx>
Tue, 21 Mar 2017 14:56:08 +0000 (10:56 -0400)
commite4fc9ad780e36c84e1ed6b0fc01b3c53ae65ff9d
tree82d15347988c014c8784a1065f5748575dbf6f34
parent16319a5df9d50cfc642ffc8db76bc36562d4b3dd
search locale name variants for gettext translations

often translations will be named only by language, whereas locale
names may also include a territory code, modifier, and codeset
portion. previously, only translations exactly matching the locale
name were loaded. this was a major usability issue, requiring
workarounds like symlinks or tweaking of the locale name.

with these changes, gettext now searches for translations by first
removing the codeset portion of the locale name, then trying the
remainder in full, with modifier (@mod) removed, with territory code
(_XX) removed, and with both removed.

part of the reason gettext lacked support for searching fallbacks
before is that the candidate pathname for a translation file was
constructed on each call and used as the key to lookup an
already-mapped translation file. this was very costly/inefficient. we
now use the tuple of textdomain binding pointer, locale map pointer,
and integer category id as the key for looking up a translation file
mapping.

based on patch by He X.
src/locale/dcngettext.c