<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>Hi Peter -- If I'm reading your post correctly... You're saying that simply invoking a locale-specific collating sequence during publishing (i.e., with no additional collating clues provided) may produce results acceptable to each locale? Unless anyone knows otherwise, it sounds like that hypothesis is worth testing: select/create a source document with enough collating edge conditions, format locale-specific versions, and have the results reviewed by locale-skilled readers. If it works, obviously it's a lot easier than building a new solution... Thanks -- Fred <hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;">On Tue, Jan 31, 2012 at 06:45:12PM +1100, I wrote: > Apparently, the mapping from a string of Kanji to its pronunciation > (ordering) isn't even a deterministic operation, at least for proper > names. (Of course I meant "proper nouns". Actual non-determinism might even be limited to proper nouns, though I'm not sure that that changes anything from a coding point of view.) > Thus, the solution would have to involve supplying pronunciations somehow > for at least some glossary entries. More precisely, it follows that sorting Kanji entries by pronunciation would in general require supplying pronunciations for some entries. However, I don't want my unclear wording to contribute to wrong conclusions about what Publican actually requires: I'm not in a position to say whether Publican requires index or glossary entries involving Kanji to be sorted by contextually-correct pronunciation. All I've learnt over the past couple of days is that *outside of* a book index or glossary, Kanji are sorted sometimes by contextually-correct pronunciation and sometimes by some other order (and I think there's more than one alternative, even). If anyone wants a concrete sample for an "is this output acceptable" question (and if not using software just for japanese sorting, like Lingua::JA::Sort::JIS), then I suggest making sure that the collation function is tailored for a Japanese locale (e.g. using Unicode::Collate::Locale->new(locale => 'ja-JP')): without that, collation software is unlikely to try to use a specifically-japanese ordering of Kanji characters or intersperse Katakana with Hiragana. In particular, the documentation for plain Unicode::Collate is explicit that it doesn't intersperse Katakana with Hiragana, and that its Kanji ordering is simply by unicode block & code point rather than by a JIS ordering. So I think the easiest thing to do that has a good chance of getting a "yes, this is acceptable" answer would be to switch from Unicode::Collate to Unicode::Collate::Locale and pass locale => $LANG to the constructor (where $LANG is the Publican language like en-US or ja-JP). Effect on other languages: Switching to a locale-sensitive collator might also make for a better collation of Indic languages (handling of virama, and some related reordering rules). Whereas if applied to Spanish for indexes, note that it might move entries like chkconfig from near the beginning of the C entries to just before D; it's not clear to me whether that's a good or bad thing for a word like chkconfig that isn't even spanish and thus arguably isn't using the Spanish ch digraph. (In both cases, I haven't actually tested the behaviour, nor have I asked a native speaker for their preferences for index/glossary sorting in technical documentation.) pjrm. _______________________________________________ publican-list mailing list publican-list@redhat.com https://www.redhat.com/mailman/listinfo/publican-list Wiki: https://fedorahosted.org/publican </blockquote> </div></body></html>