[publican-list] sortable lists, esp. glossaries

[Joshua J Wulf]

Hi Fred,

Sounds like a really interesting and useful idea!

Translation is accomplished with many projects using Zanata 
[www.zanata.org].

The workflow for translation is like this:

1. Generate pot files (Portable Object Template).
2. Use the zanata client to push to the pot files to Zanata
3. Use the zanata client to pull the translations as po files

According to my source, the matching between source xml and po file is 
on string match, not on line number. If that is the case, then if you 
don't change the content of the source xml, but only the ordering, then 
you'll be able to rewrite the source xml based on the po file.

So normally you'd go:
4. Build the translated output using the source xml and the po file for 
the target language
  For example: publican build --langs=es-ES --formats=html

With a dynamic rewrite you might go:

reorderpublican --langs=es-ES --formats=html

Which would then:
4. Copy the original xml file
5. Scan the xml copy for reorderable elements
6. Locate the reorderable elements in the es-ES po files
7. Construct a reordering based on the translations in the po files
8. Rewrite the xml according to the reordering
9. Call publican build --langs=es-ES --formats=html using the reordered 
xml file

Not sure if that's what you were thinking...

I don't know how you deal with a language like Chinese, which isn't 
"alphabetical". They must have some kind of ordering though, to be able 
to produce dictionaries.

As a hack-around, you could write it in anything. If it were written in 
Perl it might be easier to get it accepted into Publican.

I'd be happy to help you to test it if you get a prototype up and working.

- Josh




On 01/27/2012 08:24 AM, Fred Dalrymple wrote:
> Hi everyone --
>
> Just joined this list, though I've been at Red Hat for a couple of 
> years.  I'm a marketing writer in Westford, currently writing the 
> CloudForms Evaluation Guide, and have started using topic tools and 
> publican.
>
> I understand that we've generally avoided alphabetically sorted lists, 
> e.g., glossaries, in documents because the sort order may change when 
> translated.
>
> I'm thinking of prototyping a solution that would transform a list 
> into an appropriate alternate order and am interested in any 
> requirements that people might have.  For example:
>
>   * I'm assuming it should work with DocBook 4.5 (at least, that's
>     what I'm using now) -- any other versions or tagsets?
>
>   * what lists, other than glossaries, should be handled by this
>     solution? An obvious possibility is <orderedlist>.
>
>   * is there anything wrong with the general idea of deriving an
>     alternate version of a source file, to reorder designated lists,
>     as long as the original source files are not harmed? I'm leaning
>     toward doing the processing just before formatting so that it
>     would be more independent of edits.
>
>   * are there any constraints on which language the pre-processor is
>     written in? For example, perl is ok?
>
> How are translations handled?  Files are sent out, translated, and 
> returned with markup generally intact (i.e., only content translated)? 
> I see the directory structure in the document tree for each locale.
>
> A requirement that I'm planning to observe:  this approach should not 
> require changes to any content source files.  However, new, 
> independent, non-content files could be used to drive the process. The 
> only exception that I can see now is, for example, an <orderedlist> 
> might indicate that it is supposed to be alphabetized by using 
> something like role="alphabetized".
>
> Comments requested.
>
> Thanks!
>
> Fred
>
>
> _______________________________________________
> 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/20120130/9ae8eb26/attachment.htm>