[publican-list] sortable lists, esp. glossaries

[E Deon Lackey]

On 1/30/2012 9:15 PM, Jeff Fearn wrote:
> On 01/31/2012 12:16 AM, Fred Dalrymple wrote:
>> Thanks for the pointer (I didn't look far enough back in the archives).
>>
>> In general, if there is no automated programmatic solution, then I'd 
>> probably introduce an external file that would point at entries that 
>> didn't follow the programmatic default and provide either a clue or 
>> explicit sorting key -- think RDF resources (though I'm partial to 
>> Topic Maps).
>
> Requiring 1 writer to order their list is a bit spendthrift, requiring 
> 50 translators to order them just blew your budget. Doing it manually 
> just does not scale.

Would this be necessary? Would it be possible to be automatic for 
everything but the Japanese kana languages, and then collate that one 
set manually? (Fred, I demand your full engineering design now! :) )


>
> Don't ask "how can I do this" or "how can I do this in $language", ask 
> "how can I do this in 50 languages?" If you come up with 'manually' 
> then you didn't multiply effort by 50 properly or you aren't holding 
> yourself accountable for how your choices affect other people.

On the other hand, glossaries very seldom change, much less frequently 
than any other part of the book. That stability has to offset at least 
some of the cost, especially when compared to the benefits to users. (I 
have constant requests for glossaries from both management and GSS for 
JON, for example.)


>
>> Perhaps verbose, but if a machine can't figure it out automatically, 
>> what can you do?
>
> It can depend on what you are contractually required to do. 

Do we have any contracts that require that level of parity? For my own 
doc sets, I have real and known requests to include glossaries. So, I 
know that having a glossary matters in real life. My question is whether 
the concern about contracts is a hypothetical or a real consideration. 
That is something to balance as well -- a real customer and support 
request v. a hypothetical customer requirement. (Not that a hypothetical 
consideration can't also be the deciding factor -- it may be only a 
possibility but an important enough possibility to outweigh a real but 
relatively insignificant convenience.)