Database-driven manual pager suite - Patches: patch #6658, Better parsing and consideration...
You are not allowed to post comments on this tracker with your current authentication level.
patch #6658: Better parsing and consideration of LANGUAGE
Submitter: | Chusslove Illich <caslav_ilic> | ||
Submitted: | Sun 26 Oct 2008 10:19:23 PM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Done | Privacy: | Public |
Assigned to: | cjwatson | Open/Closed: | Closed |
Sun 16 Nov 2008 06:13:03 PM UTC, comment #1: |
Colin Watson <cjwatson>![]() ![]() |
Sun 26 Oct 2008 10:19:23 PM UTC, original submission:
LANGUAGE may contain more complicated locales than just aa:bb:cc. The attached patch therefore splits LANGUAGE thoroughly in man.c and whatis.c.
|
Chusslove Illich <caslav_ilic> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2008-11-16 | cjwatson | Status | None | ![]() |
Done |
Assigned to | None | ![]() |
cjwatson | ||
Open/Closed | Open | ![]() |
Closed | ||
2008-10-26 | caslav_ilic | Attached File | - | ![]() |
Added man-db-lang-order-01.diff, #16737 |
Your manp.c change looks just fine and I've committed it verbatim.
For fixing the splitting of multiple_locale, you're quite right about the nature of the bug and your fix is correct, but I think it would be better to make the code more readable while we're here and ditch all that hairy string iteration code. I've committed a rather different fix that uses strsep instead.
While I take your point about gettext's own locale resolution, it's worth noting that man does use internal_locale in other ways; specifically it uses it in duplicate_candidates to prefer pages that match the current locale if possible. Now, strictly, that code should check through multiple_locale and try to find one that matches any of the locales there, in order. In the absence of getting round to doing that, though, I think I'd rather continue to update internal_locale if LANGUAGE is set if only because that means I don't have to wonder why it isn't updated. However, the code was clearly wrong in just assigning multiple_locale to internal_locale; I've fixed it to extract the first element instead.
Thanks for your patch!