Re: [Scrollkeeper-devel] Plan for Category Tree for ScrollKeeper >= 0.4

[John F. <jf...@sw...>]

On Fri, Mar 30, 2001 at 01:12:53AM -0800, Dan Mueth wrote:
> 
>   B) mapping between C and non-C locales for categories.  This is probably
>      required in our new po-file technique of i18n.  (Note that now, the C
>      and non-C locales could have completely unrelated entries in theory.)
> 
>      Question: What should we use for our key?  Should it just be the 
>      category in C?  Or should we have a seperate attribute containing
>      some sort of a key?
> 

An attribute with a key would be more complicated to implement, but
would guarantee uniqueness.

>      * This (along with document mappings) allows us to merge
>        the category trees for two locales.  Suppose for example, that
>        there is a document installed only in C.  Using the document 
>        mapping, we could identify that it is not available in locale <xx>
>        and determine which localized category the C doc belongs under.
>        This is a feature we really need in 0.4, and the first feature
>        request I heard from translators.
> 

This would be of great value.

>   C) OMF-file category compatibility between C and non-C locales. So if an
>      OMF file for locale <xx> has a category of "string", then it tries to
>      match the "string" with the localized category tree as well as with
>      the C tree.  This way people don't have to translate a category in
>      the OMF file if they don't want to, and everything will still work.
> 
>      * This is just a practical issue.  Sometimes people forget to
>        translate the category, so this is extra rubustness. Plus, life
>        is easier if we have less stuff to translate, so we may even
>        encourage people to not translate the category for the OMF file
>        if they don't want to.
> 

This would solve a major problem I have had in creating omf files, but
authors writing in other than English should be able to use their own
language for the category name.

> 
> 4) Introduce the proper XML notation for the OMF files for categories,
> instead of using our pipe-delimeted form which is lame.  We should remain
> backward compatible with the pipe form, but strongly discourage it since
> it is inconsistant with the XML concept.
> 

Could you give an xml example of what this would look like?

> 
> 7) (not really category-specific) Look into character encoding issues and
> compatibility with the new (as-yet-unreleased) libxml.
> 

This probably needs to be done right away, doesn't it, so we are ready
for the release of the new libxml?

Cheers,
-- 
John Fleck
jf...@sw... (h)
jf...@ab... (w)
http://www.abqjournal.com/scitech/