feedback on locales needed (was Options in locales.xml)

I want to keep this process cleaner than this, so I think I’ll add a
required version attribute to the branch schema, with a value of
"1.0".

I don’t think it makes sense to add that to the cs:locales element though.

I also don’t want to have two different directories of locales files to manage.

So we’re still left a transition to manage. We need:

  1. implementers to agree to the change. I guess if I don’t hear
    otherwise, I’ll assume acceptance.

  2. to convert the existing locales file to the new syntax

  3. to actually move the implementations to supporting the new syntax

I would just add that the current syntax xpath expression for a simple
term would be:

/csl:terms/cs;term[@name=‘and’]

The new syntax would be:

/cs:locale/csl:terms/cs;term[@name=‘and’]

So an xpath that supported both would necessarily need to be:

///cs;term[@name=‘and’]

… which in theory is a little less performant.

Another way to do it would be to do:

/cs:locale/cs;term[@name=‘and’]

… which would allow:

/*/cs;term[@name=‘and’]

This would mean not adding the cs:terms and cs:options wrappers.

I think the proposal from Frank and Rintze is better from a clean XML
perspective, but the latter may be better for existing
implementations, depending on how their code is structured.

Feedback please.

Bruce

No problem with that here.

The style archive will also be affected by the change, though.
Happily only four styles contain locales info, but they will need to
be changed, and the implementations will need to use the former of the
two suggested xpath statements to extract locale data from them for
overloading. Here are the styles:

immunity.csl
mhra_note_without_bibliography.csl
tah-gkw.csl
tah-leviathan.csl

Frank