[publican-list] sortable lists, esp. glossaries

[Fred Dalrymple]

----- Original Message -----

> 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.

Hi Jeff -- 

Sorry if I wasn't clear enough. It would be a hybrid solution, where the default would be automatic translation. The external annotations would only over-ride those cases that didn't sort correctly via the automated solution. I'm all for going as far as possible with automation, but if there are cases that are non-deterministic (as Peter demonstrated), then this approach requires the least effort from writers -- unless one gives up on the entire project :). 

Yes, DocBook has anticipated some cases, but the approach I'm thinking of (1) potentially works across any elements (including those that aren't lists), and (2) doesn't require "intrusive" markup of the original source. An external file is cleaner, and allows multiple annotation sets for different uses. That's not to say that I'm committed to implementing the complete set of features and flexibility in the prototype, just showing a viable solution for glossary entries. 

Fred 

> 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.

> > 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. Like say
> if
> you were contractually required to ensure a translation had the same
> level of presentation and editorship as the source language, then
> doing
> such things in an un-automated fashion might expose you to very
> expensive repercussions.

> > Actually, I'd assumed this in the solution because I'm thinking
> > about non-alphabetic sorting needs, like the order of introduction
> > of terms, perhaps on a per-topic basis (and yes, enabling
> > solutions in forms other than print).

> DocBook already has attributes to allow this kind of sorting for some
> lists, it's useless from a translation perspective. We did consider
> modifying the translation tools to expose these attributes to the
> translators, but the issue of scale raised it's ugly head and we
> realised we couldn't afford the impact on translation time.

> Cheers, Jeff.

> --
> "Reply All" why you shouldn't use it:
> http://www.emailreplies.com/#12replytoall

> _______________________________________________
> publican-list mailing list
> publican-list at redhat.com
> https://www.redhat.com/mailman/listinfo/publican-list
> Wiki: https://fedorahosted.org/publican
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/publican-list/attachments/20120131/49168ea4/attachment.htm>