[publican-list] sortable lists, esp. glossaries

[Joshua J Wulf]

On 01/31/2012 02:50 PM, E Deon Lackey wrote:
> 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. 

Let's just say that Japanese companies are frequently very particular 
that their language is not treated as a second-class citizen.


> 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.)
>
> _______________________________________________
> publican-list mailing list
> publican-list at redhat.com
> https://www.redhat.com/mailman/listinfo/publican-list
> Wiki: https://fedorahosted.org/publican