Not clear which translator is used in which cases

[bertfrees]

Tests show that for an OBFL with a single xml:lang attribute and a single translate attribute (both on the obfl document) and when the specified locale and mode differ from those attributes, different translators may be used within the same conversion.

This may sound not so strange, but the problem is that I can't find a clear pattern in the choice of the translators. It even appears that the same part of the OBFL is translated with different translators in different phases/passes of the conversion.

Another issue is that it is not entirely clear in the specification to which parts of the OBFL the xml:lang and translate attributes of the obfl element apply.

I think the issue boils down to the question: why is it possible to specify a locale/mode in the OBFL itself, and also as options? And if the answer is that one is needed to override the other, what is the intended order?

[bertfrees]

These are my findings after studying the code:

• Text in page margins (everything within field and marker-indicator) is translated using the "default translator", which is selected based on the "locale" and "mode" arguments passed when creating the FormatterEngine.
• All other text is translated using either a translator that is selected based on the closest translate attribute and the "locale" argument passed when creating the FormatterEngine, or the default translator if there is no such attribute. The translate attribute is allowed on sequence, toc-sequence, dynamic-sequence, item, before, after, block, toc-block, td and span. Note that a translate attribute only influences the translator of content that is a direct descendant of the element. E.g. a translate attribute on toc-sequence will only influence the translation of the content with on-toc-start, etc., not the content of the referenced table-of-contents.
• xml:lang attributes (allowed on the same elements, and required on obfl) are not used to select translators, but are used as the "locale" property of text passed to the translator.
• The default translator is used to compute the margin character (the braille translation of a single space).

All above items except the first one are more or less clear from the specification, although it could use a bit of clarification to avoid any misunderstandings. The first item is not clear from the specification. This is something that should probably be changed in Dotify because it is not very logical. For starters, the translate and xml:lang attributes on obfl should influence the translation of page margins. In addition, translate and xml:lang attributes could be allowed on field, marker-reference, header, footer, margin-region and indicators (or a subset of these).

Another difference between the specification and the behavior of Dotify is that Dotify currently supports translate, xml:lang and hyphenate attributes on table-of-contents, toc-entry, toc-entry-on-resumed and list-of-references, while this is not allowed according to the spec.