Allow deferred localizing in assembly

[ascholerChemeketa]

Allow <pi:localize> elements to be written during "representations" pass that are then localized during "language" pass.

Localize static reps of Runestone activities

[rbeezer]

A long time reading through this one with a bit of testing. Correct me if I misunderstand someplace.

• I thought a lot of this was to place a @locale-lang on every element. Testing with "assembly-static" from the pretext/pretext script suggests that is wrong. So I must not be reading something right (which is concerning). And I'm uncertain why there are so many changes (I do see how @force-language is used, see below).

• Before/after "assembly-static" with sample article: 3 "Incorrect" have gone missing it seems. Two in multiple choice (in an li/title), one in a clickable area (with trailing colon). A little bit of looking did not suggest to me what is wrong. (Notice that a lot of automatic id's see changes due to a new element pi:localize floating around. I don't think this is a problem since it is inside a "representation". It is a problem over on Publisher pagebreaks #2618 where new elements went in at the "block level". Remember having our fingers crossed?)

• Before/after "assembly-dynamic" with sample article checks out fine.

• On -dev you said

I was not able to use a modeless template in common to handle <pi:localize>. There were too many spots where ancestors ended up making assumptions about their contents and not calling apply-templates on things they were not expecting.

This one has been keeping me up at night. I don't understand why a template in -common can't simple apply the "type-name" template with the @string-id value and let that whole procedure do its thing. Inserting the @force-language parameter to short-circuit that process does not feel right to me.

[ascholerChemeketa]

I thought a lot of this was to place a @locale-lang on every element.

No, the param is just being used to keep track of the nearest specified language in the ancestor chain. That is what we want to use when we hit an item to localize. The normal lookup process for type-name won't work as our context is the tree that lacks language attributes, not the new one we are building with attributes.

I don't understand why a template in -common can't simple apply the "type-name"

I could be missing what you are suggesting or something about XSL. But my understanding is that this won't work because the engine starts with a virtual call to xsl:apply-templates select="/". So if nothing in the chain started by that calls a template, it won't execute. In this case, various templates don't call apply-templates to their children, they assume there is text() or something else they want to render.

We have a situation like this. In that demo, the <li> template never fires because <ul> stops the chain. We are in an analogous situation, only instead of one dead-end, there are a bunch and no good way to identify them.

Will look into missing items once strategy is resolved.

[rbeezer]

Thanks for the explanations. That helps.

Let me take this and see if I can't get pi:localize to behave with a template in -common. Off-duty much of today, but will look soon.

[rbeezer]

they assume there is text() or something else they want to render.

That is certainly true. So pi:localize cannot go just anywhere. But it can go in things like a p or a title or an li or a caption. And we control what a representation looks like, not an author.

In that demo, the

template never fires because

stops the chain.

Right. But we would never do that. We don't do that. Said differently, a localized term like we are working on would never (say) be a child of an ol and get "missed".

[rbeezer]

Took your commits and built the LaTeX file. Hacked on the PR:

• Neutered additions to the language pass in -assembly.
• (Basically) moved the template matching pi:localize to -common.

Identical result for the LaTeX output file. $curr-lang was not used in -common. So...I think this approach will work and is is much cleaner. I could buid on this with a follow-on commit? Or how might you like to proceed?

[ascholerChemeketa]

I realize I should have made two commits on the RS static localize. One change removes a duplicative True or False string. The title of TF questions gets \lititle{True\slash{}False.}, so adding True or False at the start of the statement looks weird.

When I do what you describe, I see the following changes to the tex output:

• True or False? string gone (good)
• uncategorized gets capitalized (expected)
• Data goes missing from before datafiles (bad)

The last one is the one that got me worried about things not making it through. Looking deeper, it looks like the reason is that the <pre> that representations generates gets decomposed in -latex with:

<xsl:template match="pre">
    <xsl:text>\begin{preformatted}&#xa;</xsl:text>
    <xsl:apply-templates select="." mode="interior"/>
    <xsl:text>\end{preformatted}&#xa;</xsl:text>
</xsl:template>

And mode "interior" ends up only grabbing text content, not processing the <pi:include>.

"Why the hell didn't 'Data'" make it to the output drove me nuts for a while. I am worried about similar headaches for even less experienced dev's who add a <pi:localize> to somewhere and then can't figure out why it doesn't make it into output. Maybe once the issue is located, it is fixable without too much effort. But I can imagine a situation in which the spot <pi:include> gets dropped from the output is a tricky fix that involves modifying multiple templates to pass neutered content along so that eventually we get the <pi:include> to trigger.

So where you see a simpler current change, I see a fiddly set of future changes. The slightly bigger current change that just works on any future uses of <pi:include> seems much simpler in the future.

[rbeezer]

I understand the problem, and agree with your hesitancy. But

for even less experienced dev's

It is not our job to hold the hand of experienced devs when they tackle something beyond their understanding. I put a lot of effort into steering a new contributor to something they can tackle, versus suggesting somebody else should do it. The person and the code are different each time. ;-) I'm hesitant myself to mess with -assembly (a situation I want to improve when I can get a clear shot at -assembly).

So I find processing pi:localize in -common the better option.

• I will look harder at the pre problem.

• With the introduction of pi:localize to the representations pass it should come with clear warnings about the situations you describe.

[ascholerChemeketa]

OK.

If you want to merge what you have once you figure out the pre's, I'll watch for it and update QRCode PR based on results.

[rbeezer]

Alright, just saw your latest. Ideas below if you have further input.

pre is a peer of p. So just put <p>Datafile <c>foo.txt</c>:</p> into the source right before the pre. Yes, it will be indented. Hopefully, the new p does not upset subsequent visible-id. (I fear it will, and may cause a mismatch with earlier assembly-id. Maybe not so critical for static?)

I guess we need to replace datafile with one element. This is a hack:

sidebyside - 100%
  stack
    p (datafile filename)
    pre (contents)

And maybe that lone p in a stack does not get an indent? ;-) Or a real sidebyside with a very skinny first panel with two lines: "Datafile", filename, then the file contents in a wide second panel.

I prioritize "legal" PreTeXt and accurate content for the representations, over style. Some of the lists for things like multiple-choice could look better. We could implement things like

p/@pi:indented

to improve the looks, but they need to be implemented across all output formats that are static.

[ascholerChemeketa]

I like the stack. The datafile already may have width problems... trying to put the title next to it is going to almost guarantee it.

Will do my best to not care about the indentation on

's inserted here and in QRCodes.

[rbeezer]

Ooops, I wrote "experienced devs" when I meant to say "inexperienced devs". I hope you didn't think I was taking a swipe at present company! (I wasn't!). I'll go ahead and break this up into some commits from you and some from me.

[rbeezer]

Merged. Three commits - two for you, one for me.

I think datafile looks good. Except for indentation.

Thanks for your work puzzling though this one.