Naming of tags local_bibdata and i18nyaml

[ronaldtse]

From metanorma/mn-native-pdf#270 it seems that we have source data like this:

Source data: /bipm-standard/local_bibdata/i18nyaml:

<i18nyaml>
...
	<i18n_see>see</i18n_see>
...
</i18nyaml>
<i18nyaml>
...
	<i18n_see>voir</i18n_see>
...
</i18nyaml>

This naming seems very weird -- yaml shouldn't be mentioned in the XML, and local_bibdata seems like a strange way of naming. i18n_see is also very strange.

Can we generalize this with a more appropriate naming scheme?

[opoudjis]

I'm (somewhat) open to suggestions.

• local_bibdata was meant to be local-bibdata: there is code in the asciidoc branch that replaces underscore with hyphen in tag names, but I forgot that this is injected in isodoc branch, so that renaming does not apply. I take it local-bibdata is OK?
• I could just name the internationalisation section of local-bibdata i18n or internationalization
• I do want the the tags within the internationalisation section to be prefixed, because very bad things will happen to existing code if I reuse tags that also occur in the main document (such as clause). Is i18n-see acceptable?

[ronaldtse]

How about <bibdata lang="en"> vs <bibdata lang="fr">? Or having a single <bibdata> with multilingual content.

Something like this?

<metadata>
  <language>en</language>
  <language>fr</language>
</metadata>

<bibdata>
  <status>
    <stage>
      <label lang="en">in force</label>
      <label lang="fr">en force</label>
    </stage>
  </status>
</bibdata>

<localized-strings>
  <localized-string key="see" lang="en">see</localized-string>
  <localized-string key="see" lang="fr">voir</localized-string>
</localized-strings>

[opoudjis]

@Intelligent2013 Raising this for your attention.

[Intelligent2013]

I can change xslt to process any structure.
But I need to know what is language of current processing document, i.e. bibdata/language should be determined unambiguously.

[opoudjis]

I am starting this comment by saying that these changes are counterproductive.

@ronaldtse: @Intelligent2013 is right, I will continue to resist the fanciful notion that a document is in two languages as a perversion. A document as a semantic unit is in one language at a time. Bilingual documents are juxtapositions of two documents in separate languages. There shall be one language in //bibdata/metadata. However, because I cannot prevent future boneheadedness (and I regard this ticket as such), I will also add a current attribute to the language represented in the document, just in case.

I am dropping local_bibdata, because Ronald. Instead, I am adding language tagged variants to all enums translated in Presentation XML. There shall always be a language-independent value for such enums, and it shall be indicated as lang="".

instead of i18nyaml, I will use the localised strings mapping dictated by Ronald above.

And metadata IS bibdata, what the HELL are you doing by splitting them up?!

So, a French-localised document will read:

<bibdata>
  <language current="true">fr</language>
  <status>
    <stage language="">in force</stage>
    <stage language="fr">en force</stage>
  </status>
</bibdata>

<localized-strings>
  <localized-string key="see" lang="fr">voir</localized-string>
</localized-strings>

An English-localised document will read:

<bibdata>
  <language current="true">en</language>
  <status>
    <stage language="">in force</stage>
    <stage language="en">in force</stage>
  </status>
</bibdata>

<localized-strings>
  <localized-string key="see" language="en">see</localized-string>
</localized-strings>

A lang="en" variant will not always be available; so any text rendering of stage will need to use //bibdata/status/stage[language = "{current language}" or language = ""]

Ronald thinks it makes sense for there to be a fully bilingual document, that looks like:

<bibdata>
  <language>en</language>
  <language>fr</language>
  <status>
    <stage language="">in force</stage>
    <stage language="en">in force</stage>
    <stage language="fr">en force</stage>
  </status>
</bibdata>

<localized-strings>
  <localized-string key="see" language="en">see</localized-string>
  <localized-string key="see" language="fr">voir</localized-string>
</localized-strings>

it doesn't, and that's not how we're going to implement bilingual documents. It never was.

[opoudjis]

instead of i18nyaml, I will use the localised strings mapping dictated by Ronald above.

On second thought: no I will not.

i18nyaml right now is an XML dump of the contents of the YAML i18n file for the current language. That includes nested i18n lists, such as:

admonition: {
  danger: Danger,
  warning: Warning,
  caution: Caution,
  important: Important,
  safety precautions: Safety Precautions
}

What am I supposed to do with that? <localized-string key="admonition.danger" language="en">Danger</localized-string>? What if there are arrays in there? Am I supposed to create JSON Paths for all these keys?

I can do it. I just think that this too would be counterproductive.

[opoudjis]

Correcting behaviour of metadata class in isodoc: extract document titles in current language, not in English.

[opoudjis]

ITU impacted:

<ext>
  <structuredidentifier>
    <amendment language=''>1</amendment>
    <amendment language='en'>Amendment 1</amendment>
    <corrigendum language=''>2</corrigendum>
    <corrigendum language='en'>Corrigendum 2</corrigendum>
  </structuredidentifier>
</ext>

[opoudjis]

Doing this after all:

<localized-strings>
  <localized-string key="see" language="en">see</localized-string>
  <localized-string key="see" language="fr">voir</localized-string>
</localized-strings>

with JSON paths for the keys, in case the YAML file has embedded values.