Fixing HTML on legacy texts

[sujato]

Sorry about the delayed response, let me go through these.

@Aminah

Tinkerings to-date have been pushed to the html-clean5 branch for checking and and can wait there until Hongda is ready to update the site code as necessary.

Okay, cool. As noted in our meeting, revising the text pages is the next step for Hongda. I have focused on the segmented texts, but the legacy texts are included as well. When Hongda is ready to start working on this, we should get him to use this branch.

@Aminah

A closer peek is also needed before adding lang attributes and can’t (accurately) be done in a blanket fashion

We should probably assume <i> = <i lang="pli"> unless otherwise defined. It won’t have a practical implication immediately, but I am still looking at, for example, a terminology dictionary where this would be useful.

@Aminah

I think the numbers are now right

great, thanks.

@Aminah

.fakechapterhas been made redundant in the process

Indeed, let’s scrap it.

@Aminah

the whole <div class="hgroup"> (now <header> ) across the different language translations just require individual attention to treat the many slight variations correctly,

Okay.

@Aminah

The purpose of this was to produce a single “range-title” h1 per file with individual suttas titles becoming h2 as previously agreed.

Okay.

@Aminah

where a vagga-sutta contains several suttas under h2 titles, these have each been wrapped in <article> tags.

Great, and difficult cases are noted. We should ensure that these cases at least display reasonably sanely, but if the system is a bit wonky, never mind.

@Aminah

<footer class=“metaarea”>

Does this need a class? There will only ever be one footer in a sutta. “Footer in a sutta”

@Aminah

In vagga-sutta files with multiple suttas in articles

Will individual suttas in such cases have IDs?

To make sure we’re on the same page, and include @blake in this, there are two cases:

• Where a vagga-sutta has no individual suttas, use the range for ID only.
• Where a vagga-sutta includes individual suttas, use the range for the file ID, but sutta IDs internally.

I made a list of these debakable texts.

List of concatenated texts for debaking

Concatenated texts are those where more than one “sutta” is contained within a single file. For this list, I only include those texts that may be meaningfully split into the respective suttas. If we are to adopt the principle of not baking presentation assumptions into text data, then these are candidates for debaking. The segments of each of these need to be renamed from the range ID to the individual sutta ID. Note that the distinction between debakable and not debakable texts usually follow…

I will take a look at the sutta segments and ensure they are all correct.

Note similar issues are encountered in the Vinaya Sekhiyas and Adhikaranasamathas, and elsewhere, umm, maybe the bhikkhuni patidesaniyas.

In the case of legacy texts, this may well fall into the category of “too messy to fix”, which is fine, but we should be clear about it.

@Aminah

One not “bibbly-bobbly” bit I’m keen to look at, that nevertheless hasn’t been approached yet is adding structured data (perhaps with schema.org’s vocabulary). Of course, this probably overlaps with the RDF ticket, which I’m also quite interested in.

Well, let’s get the HTML finished and live, then we can look at this. Turns out Anders is not looking likely to get this done!

@Aminah

I discovered all dates follow the ISO_8601

Good to know.

@Aminah

pay to know how to write the date correctly

Yeah, not good.

@Aminah

it might be nice to make a “finalized” reference point

Yes, indeed, we should preserve a proper spec on the wiki.

@Aminah

one thing that would be good to check over, tweak and confirm is the the supertitle section.

Best leave it where it is for now, and let’s implement the bilara texts properly, then we can see if there are lessons to be learned for the legacy texts.

One possibility is to create the supertitles dynamically based on bilara-data. Then we could even throw a nice little display:none on the hard-coded supertitles in legacy texts and deliver the same supertitles as the segmented texts. clutches pearls

@Aminah

you probably already know, but WHATWG has now become the sole keeper of the HTML standard.

So sweet, everyone is getting along!

@Aminah

While on the one hand stating “we should use the same basic principle of following the naming as used in the sidebar”, it’s also mentioned that “all classes in supertitles should be in Pali.” I don’t see how both of these guiding principles can be followed in the case of non-Pali texts.

The main point, I think, is simply that we use the same naming system as found in the sidebar. For Pali texts, this will be in Pali, in other cases … let’s see!

Okay, in SA we immediately have a problem, the grouping is simply by the hundred suttas. this is purely arbitrary, as the Taisho doesn’t represent the samyuttas properly, and the text is in any case disordered… Actually this should be structured to follow the Samyutta structure, but it seems unlikely that this will happen in the Taisho anyway.

For EA, the sidebar number is just ea2, etc. This is not really useful.

Hmm, well perhaps this is a problem in search of a solution. It is only really in the Pali texts that the hierarchy is both spelled out in detail and acyively used. Why not limit the scope of this to apply only to Pali texts? In any case, these are the only segmented texts, so other cases are purely theoretical for now. Let’s leave it until we create other segmented texts.

@Aminah

Is the basic idea to map non-Pali structure onto the Pali model?

Not really, no.

@Aminah

.headertitle

Umm, not sure about this now. The idea is to have a simple way to target all things that are titles, which would include things both inside the <header> and outside. If it is just stuff in the <header> we can simply scope it that way. But if it is to include titles that are included within vagga-suttas then headertitle or whatever doesn’t work.

Maybe we’re overthinking it. Can we just ignore this idea and hope it goes away?

@Aminah

just beginning at <header> . I pointed out this wouldn’t necessarily work for the legacy files as the author name is given in the <head> area. However, <meta charset="UTF-8"> can certainly get the chop.

Indeed.