-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for multiple values for schemaSpec/@docLang #136
Comments
Stylesheets group met today and discussed this ticket. It brings up lots of interesting XSLT issues if you dig down into it, but the higher-level issue of interest is What should happen if a
And, of course, the RELAX NG would correspond: 1. Four separate schemas, 2. One schema where each component gets a corresponding annotation that has a single description in one of four languages (in the order of preference specfied), 3. One schema where each component gets a corresponding annotation that has (up to) four descriptions in different languages. |
If oxyGen can handle it, my preference (which I thought I had stated on the ticket) would be for option 3. If not, option 1. Option 2 is not one I would entertain. |
The more I think about it the more I'm starting to favour number 3. That said, isn't a fourth option to have a processing parameter that says how to deal with this in schema generation? (i.e. to take all or take this specific one(s)?) Maybe that is the intent behind the many language-related parameters we have already that @martindholmes mentioned. |
There is also a fifth option, which is to flag provision of multiple values as an error, or at least "not currently implemented". That would be the easiest option! |
Yea, verily. So, in order of my guess at degree of difficulty:
|
Option 2 (but not necessarily option 3) implies that the order of the components of a multivalued attribute string is significant. So I dislike it. |
@martindholmes points out that the schema and the HTML (or ePub or whatever) output do not have to have the same solution — schemas should probably always have all langues. (Solution (3) for schemas, undecided for documentation.) |
Stylesheets group agrees that this is important to do after translations have been improved, but still not particularly high priority, and until then outright low priority. So we agree to go with solution (5) for now until #138 is dealt with, and perhaps we have a better system in place for getting improved gloss and description translations faster. |
@sydb to add wanring message, all to test and see if we think the output thereof is sufficient warning. |
Another option would be to generate two separate versions of the schema initially, but then merge them in a subsequent operation. That might actually be much easier to accomplish. |
Was I supposed to add this warning message to the ODD processor that finds 2+ values on |
The value of @doclang on schemaSpec is used to determine which <desc> elements are passed through to a RELAXNG schema as documentation elements, subsequently to appear as popup tool tips in oxygen. At the moment if multiple languages are specified (e.g. @doclang="de fr") this is interpreted as a single value "de fr" which does not exist, and the documentation is thus generated in English by default. It would be better either to flag this as an error, or much better to generate multiple documentation elements, each with an appropriate @xml:lang, which oxygen can then use appropriately.
Issue raised on TEI-L by Matthias Muller on 2016-02-03
The text was updated successfully, but these errors were encountered: