Re: Merging en & ja jlreq (glossary)

dear jlreq-team,

We need to decide how to handle the glossary in the multilingual jlreq 
document (see 
https://w3c.github.io/jlreq/temporary_bilingual_devt/#appendix_7).


APPROACH 1

Currently, because the ordering is different in english and japanese, 
the two tables of terms have not been merged. If you filter the document 
for english only, the whole japanese term table is hidden, and vice versa.

There are two issues with this approach:

1. each of the 180 rows in each table has an id, so that you can link to 
the term definition from the main text, and in the old jlreq for a given 
term that id was the same, whether the table was the english one or the 
japanese one.  Having the same id twice in the document causes 
validation errors and causes problems for linking, so for now i renamed 
all ids in the japanese table to start with "ja-".

2. if we continue to have separate tables with language-specific ids, we 
need to change all the links to the japanese term rows throughout the 
rest of the text. Given that there are around 180 terms, and many if not 
all are pointed to from the main text several times, this is a big job 
if we are to do it by hand.  It's more complicated than global search & 
replace because we mustn't change the links to the english table.


APPROACH 2

An alternative approach, which still involves a fair amount of work, but 
maybe less, would be to merge the two tables.  The downside of this 
approach would be that the rows in the table would be ordered by the 
english sort order, rather than the japanese (because english is the 
authoritative version of the doc).  Is this an issue?

Also, the japanese table has a yomi column, whereas the english table 
has a romaji column.  Should we keep both ?

We may be able to add some scripting, so that when a user chooses 
english or japanese then the order of the table is changed.  (The 
default multilingual order would probably need to remain as english 
ordering.)  It would involve a fair amount of processing – particularly 
if the aim including rearranging the columns, as well as the rows – i 
don't know whether it would result in a perceived delay in displaying 
the page.



At this stage, i just want to get some feedback on which approach you 
think would be better.

thanks,
ri

Received on Wednesday, 1 May 2019 12:30:57 UTC