w3c / jlreq

Text Layout Requirements for Japanese
https://w3c.github.io/jlreq/
Other
100 stars 16 forks source link

Language switching doesn't work for the spec metadata #260

Closed xfq closed 4 months ago

xfq commented 3 years ago

After clicking 日本語 in https://w3c.github.io/jlreq/, the spec content is changed to Japanese, but the spec metadata section ("This version:", "Latest published version:", "Latest editor's draft:", "Editors:" etc.) is still in English.

https://www.w3.org/TR/jlreq/ works fine.

himorin commented 3 years ago

mm.. working for me now. could you try to reload (or super-reload??) and test?

xfq commented 3 years ago

I tried it in Chrome 89, Safari 14.0.3, and Firefox 87 after clearing the cache and disabling the extensions, but it still doesn't work for me.


Expected result:

expected

What I saw:

happened
himorin commented 3 years ago

one possibility is a processing order of scripts. let me take some time to rewrite current switching initialization code using postProcess of respec, not onload.

r12a commented 3 years ago

My experience is as follows:

/TR works as expected on Firefox, Chrome, Safari ! (so we should carefully check whether something changed in the ED...)

Editor's draft: Firefox works Safari doesn't work Chrome didn't work until i installed the latest version (!) but now works The version i'm now using is Version 89.0.4389.114

This is all on Mac Big Sur.

@himorin i suggest trying to understand the changes that lead to the problem in the ED before rewriting the code. If it works in TR but not always in the ED, what changed?

himorin commented 3 years ago

Not a root cause, but the behavior seems "adding id to dt" is failing. /TR/ has processed HTML tree by initialization code, but ED is not. While reloading many times, I've encountered longer run of respec script and got an warning that some deferred scripts were not called xx seconds after load (or something similar), and got the same behavior (labels does not change with switching language).

For "doesn't work" ones, could you please try to:

If this fixes, the root cause is functions set to onload run before end of respec processing (adding head section incl. the part under discussion).

himorin commented 3 years ago

One possible change could be some W3C API (used within respec) returns with longer processing time than before...

xfq commented 3 years ago

For "doesn't work" ones, could you please try to:

  • open developer console (or something similar one, usually via F12)
  • go to 'console' tab, and type 'setFrontMatterIds()'

If this fixes, the root cause is functions set to onload run before end of respec processing (adding head section incl. the part under discussion).

Running setFrontMatterIds() in the console indeed fixed the issue for the editor's draft.

And I just tried reloading the /TR version a few times and found that it doesn't work sometimes (and setFrontMatterIds() can fix it too).

himorin commented 3 years ago

Thank you for confirming that setFrontMatterIds() fixes the issue. And interesting for /TR version.. One possibility, we have defer on script loading, and using body onload for execution. So missorder of execution could happen which results to undefined error of functions set to onload,,,??

Anyway, I think all could be fixed with moving setFrontMatterIds into postprocess of respec (and having initialiseLang at both onload and postprocess?), since it will build processed HTML tree (with appropriate id-s to dt-s) - adding id-s after HTML tree built by respec for ED and statically for /TR.