Digit formatters in gnome-doc-utils

[Shaun McCance <shaunm gnome org>]

Currently, to format the number for a section,
the section.number localization is called up,
which might look like this:

<parent/>.<digit/>

This formats the parent number, whatever that
may be, and the "digit" for the section, which
is just the position of that section in its
parent.  The digit formatting is then controlled
by the section.digit localization, which is just
a single-character thing saying what numbering
system to use to format it.

If a section is a top-level, the section.number
localization is bypassed and section.digit is
called directly.

The problem is that at least the French team
needs to do formatting on the digit:

http://bugzilla.gnome.org/show_bug.cgi?id=315190

This particular case involves wrapping the digit
in some markup, which you can't do reliably with
the current system.  You could wrap the call to
<digit/> in the number formatter, but that won't
help you when the number formatter is bypassed
for top-level things.

Here's some possible solutions:

1) Get rid of the single character digit things,
and instead put attributes on any call to digit.
This, you'd have something like this:

<parent/>.<digit format='1'/>

I would then remove the current digit formatter
localizations, but I'd have to add localizations
for top-level things.  Net result is the same
number of localized strings.  This could also
potentially be a tad faster, as template depth
gets reduced.


2) Do the same thing, but instead of attributes,
use special named elements, like so:

<parent/>.<digit1/>

So we'd have digitI, digiti, digitA, digita,
and digit1.  This annoys me, though it could
potentially emphasize more the need to mark
the formatter.  It has the same advantages
as the first option.


3) Keep number formatters just as they are,
but turn digit formatters into things that
can have markup.  So section.number would
still just be

<parent/>.<digit/>

But section.digit would become

<n format='1'/>

Where n would have to become some meaningful
element name.  This has the advantage that
only digit formatters have to be changed,
and the change can be done automatically.
I could even adjust all the PO files, if
translators wanted me to.

The other advantage is that you still only
need to specify the digit formatting in a
single place.  It does, on the whole, seem
cleaner to me.

On the other hand, it means I have to come
up with yet another element name, I think.
Due to the way XSLT works, and the way my
i18n system works in XSLT, I probably can't
just re-use "digit" or "number" as element
names here.  And I'm sort of at a loss for
another element name to convey the meaning.


Thoughts?

--
Shaun