-
Notifications
You must be signed in to change notification settings - Fork 4
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
Add Jamo and Kana #52
Conversation
Fix #41.
✅ Deploy Preview for i18n-glossary ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
index.html
Outdated
|
||
<div class="letter_anchor" id="k">K</div> | ||
|
||
<p><dfn class="lint-ignore export">Kana</dfn>. <a href="https://unicode.org/glossary/#kana">Unicode definition</a>: <q cite="https://unicode.org/glossary/#kana">The name of a primarily syllabic script used by the Japanese writing system. It comes in two forms, <i>hiragana</a></i> and <i>katakana</a></i>. The former is used to write particles, grammatical affixes, and words that have no <i>kanji</i> form; the latter is used primarily to write foreign words.</q></p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are 2 stray anchor end tags. Note that our i18n checker will pull you up because there is no class name on the i tags – presumably that's a carry over from the Unicode text, but i don't think we need to retain their markup when we can do better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are 2 stray anchor end tags.
Removed.
Note that our i18n checker will pull you up because there is no class name on the i tags – presumably that's a carry over from the Unicode text, but i don't think we need to retain their markup when we can do better.
Do you have any suggestions on how we should change it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After puzzling for a while as to what the markup was supposed to indicate semantically (which illustrates the problem here), i looked at the Unicode source. The original text has em, not i, markup, which implies that this is presentational markup. However, those words are actually linked to glossary definitions.
We could change the i elements to links, pointing either to the Unicode glossary or to 2 new entries in our glossary, and that would probably distinguish the words sufficiently. Otherwise the closest thing in our style guidelines is class=qterm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although I'm okay with defining hiragana and katakana in this document, I don't want to define Kanji here, because if we define Kanji, I think we should also define Hanzi, Hanja/Hancha, and maybe even Sawndip and Chữ Nôm. After consideration, I decided to point to Unicode's definition and not define these terms in this document for the time being.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving, but consider my comment about the unicode.org links.
|
||
<div class="letter_anchor" id="k">K</div> | ||
|
||
<p><dfn class="lint-ignore export">Kana</dfn>. <a href="https://unicode.org/glossary/#kana">Unicode definition</a>: <q cite="https://unicode.org/glossary/#kana">A collective term for the two syllabic scripts used (along with <a href="https://unicode.org/glossary/#kanji">kanji</a> and <a href="https://unicode.org/glossary/#romaji">romaji</a>) by the Japanese writing system. The two forms are <em><a href="https://unicode.org/glossary/#hiragana">hiragana</a></em> and <em> <a href="https://unicode.org/glossary/#katakana">katakana</a></em>.</q></p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the unicode.org links, should we do target="_blank"
? Those links take one away from our glossary. Ideally those should link locally to our glossary (and our glossary expose those terms for those who need it)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, all unicode.org links in this document do not have target="_blank"
. If we want to add it, I can raise a separate issue/PR to discuss this. I agree with this, FWIW.
Regarding local links, I also agree, but sometimes we don't have relevant items in our glossary, and if we have them, I will link to the local ones.
Fix #41.
Preview | Diff