Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove example 8 figure 3 to avoid canonicalising a not-yet-established approach #22

Open
r12a opened this issue Jun 20, 2024 · 6 comments
Labels
i18n-clreq i18n-jlreq i18n-mlreq i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. Needs: Edits A decision has been made, but the editor has yet to reflect it in the specification.

Comments

@r12a
Copy link

r12a commented Jun 20, 2024

2.1. The ruby element > Example 8 > Figure 3
https://www.w3.org/TR/html-ruby-extensions/#jukugo-ruby

Understood: All 3 examples are jukugo ruby, meaning that the bases and annotations are individually linked, and the ruby element can be split across a line, taking all necessary annotations with the wrapped base(s). This comment is about the arrangement of the hiragana characters above the kanji when all sit on the same line.

Example 2 shows an arrangement that is described in JLReq, where at least one of the hiragana in an annotation must appear above its related base. (If 都 was annotated by 3 hiragana a gap would open between the base characters.

Example 3 shows an arrangement that looks the same as group ruby would look, and where the と annotation doesn't appear (or barely appears) over the 都 base, because all characters are justified across all the bases (which is what you'd expect for group ruby). I think there was some throwing up of hands at some point by people who feared that jukugo might be a little complicated to implement, "so let's just say that it should look like group ruby", but i don't think that that is yet formalised. Having example 3 in the spec makes it appear to be a valid option.

I suggest that we remove example 3 until such time as a decision is taken by the jlreq group about whether jukugo ruby could actually appear like this. And if that does turn out to be a valid option, i think we should make it very clear that the arrangement of hiragana over kanji in jukugo ruby can follow different rules, rather than giving the impression that the arrangement in fig 3 is the one canonical way to approach the arrangement when the ruby text is set to 60%.

typo: Correct “jukugo ruby” is not be possible

@kidayasuo
Copy link

kidayasuo commented Jun 25, 2024

Discussed at today's JLReq TF meeting.

JLReq explains that jukugo-ruby will be rendered just like group ruby when the whole base text fits within a line. In its Appendix F, it explains a more sophisticated method, illustrated in the first example as well as Figures 1 and 2 in the link.

The main author of the JLReq feels that explaining the sophisticated method as something that is expected is a bit too much. This is because the method is far more complicated. The TF members agreed.

Additionally, we feel that the example used is not optimal because it allows multiple interpretations. For instance, you can treat 京都 as one jukugo and handle 市 separately, or you can treat 京都市 as a whole as one jukugo. Bin-sensei suggested using an example like the ones below. These are three-character jukugo and contain a Kanji that has a three-character furigana. Of course you can come up with similar examples.

表沙汰 おもて-ざ-た
油絵師 あぶら-え-し
頭文字 かしら-も-じ
磁気嵐 じ-き-あらし
抄紙機 しょう-し-き
浄瑠璃 じょう-る-り

@frivoal
Copy link
Collaborator

frivoal commented Jun 26, 2024

This is not a layout spec, so we're not requiring any particular rendering, just illustrating that "Whether—and how much—the annotations are merged can vary". CSS may constrain it in various ways, but that's not the point here. The point is to show that for CSS to even have the ability to informatively decide what the rendering will look like, it needs sufficient structure and information in the markup. So, I think that the various types of renderings displayed are fine.

On the other hand, I think @kidayasuo's suggestion to switch to a word that unambiguously has 3 base characters, rather than 京都市 which can be seen as that or as two words, is a good idea.

@frivoal frivoal added the Needs: Edits A decision has been made, but the editor has yet to reflect it in the specification. label Jun 26, 2024
@kidayasuo
Copy link

Understood. Thank you for the clarification.

@frivoal
Copy link
Collaborator

frivoal commented Jun 27, 2024

That said, I wonder: are the words provided by @kidayasuo that different? While they are 3-kanji based words, it seems to me that all of them could also be seen as a 2+1 compound, in a way that's not so different from 京都市

  • 京都市 = 京都+市
  • 表沙汰 = 表+沙汰
  • 油絵師 = 油絵+師
  • 頭文字 = 頭+文字
  • 磁気嵐 = 磁気+嵐
  • 抄紙機 = 抄紙+機

Maybe 浄瑠璃 is the only one that cannot be broken down in that way (or maybe you can with 浄+瑠璃?), but it's a pretty obscure term for non-Japanese speakers.

@himorin
Copy link

himorin commented Jun 27, 2024

In many documents or filling-in forms '京都市' may be written in separated way, like form has '市' and add '京都' or listing multiple names of cities. So, for Japanese, it may be more natural to separate this word, than any other examples.

@kidayasuo
Copy link

I agree many of them still can be seen as 2+1 compounds. 表沙汰 or 浄瑠璃 will be better examples.

As for 表沙汰, however 沙汰 can be an independent word probably nobody thinks 表沙汰 as 表になった沙汰. It might be similar to English words dead+line or key+board.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n-clreq i18n-jlreq i18n-mlreq i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. Needs: Edits A decision has been made, but the editor has yet to reflect it in the specification.
Projects
None yet
Development

No branches or pull requests

4 participants