Re: Merging en & ja jlreq (glossary)

This is a hard one.

For the maintenance it would be easier if the table is unified between English and Japanese.

Then the sort order issue. Personally I will do search rather than manual browsing of rows. In that sense I do not so much care. However, I prefer not to have English sort order in Japanese page. I once in a while I find such a table on the web and they look pretty unprofessional.

Providing a script you described would be one way. One concern is the hit on the performance for the section people would not visit for 99% of the case. Another possibility, without knowing how hard it might be, might be to provide sort buttons?

(unrelated but does W3C have documents showing guidelines for localising web contents? if not, isn’t it something w3c wants to take a lead on? There might be issues that can be better solved by new specifications)

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

probably. or can we filter them depending on the language?  they can be in the same column or separate columns.


Is there an issue with the column order when unified? One excuse for having English sort order on Japanese page might be to show English terms on the first column and clearly show that this is the header. then sorting on English terms would look at least natural (regardless of if people find it convenient).

- kida

> 2019/05/01 21:30、r12a <ishida@w3.org>のメール:
> 
> 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 Thursday, 2 May 2019 02:56:24 UTC