Discoverability is a problem for this site, and I want to discuss one particular problem that I think is specific to JLU:

If you search for romanized Japanese on Google, you won't find results written in kana or kanji; if you search for kana or kanji, you won't find results that are written using romanized Japanese.

Let's use the latest question as an example:

  1. If I search for what is the difference between 部屋 and 室, it's the top result;
  2. If I search for what is the difference between へや and しつ, it's the top result again;
  3. If I search for what is the difference between heya and shitsu, it's nowhere to be found.

Now let's pick a question with rōmaji and search for it:

  1. If I search for why are there two versions of the kanji for tsumetai, it's the top result;
  2. If I search for why are there two versions of the kanji for つめたい, it's nowhere to be found.

People discover JLU by searching for kana and kanji, but people also discover JLU by searching for romanized Japanese. It seems unfortunate that searchers must choose the same orthography as askers in order to find our site.

Is there something we can do to improve this situation?

EDIT: See also the discussion in cypher's answer to the linked question.

share
1  
I may not be in the majority (and this is an ongoing controversy anyway), but for my money: Romaji is evil and has no place in any intermediate discussions of Japanese. In this particular instance, you can also add the headache of dealing with different romaji systems. – Dave Mar 9 at 2:53
I agree this is a massive problem. If it's kana, or a kanji with furigana in the title, converting that to ro-maji should not be terribly hard from a technical perspective (of course there is the problem of different romanization systems, though). There is also the question of where in the page it'd go: the <title>, the header of the post, somewhere hidden (<meta> or hidden with CSS), somewhere in the post (near the tags, perhaps?), or some combination of those things. – Darius Jahandarie Mar 9 at 3:20
3  
@Dave I concur that ローマ字 has no place in high-level discussion, and despite that, I think findability of our posts is terrible due to the lack of ローマ字, because not everyone shares the same ideology (or experience with kana+kanji, or motivation to try to search for something multiple ways). I think the only way to solve this is a technical solution which tells Google the readings in ローマ字, that way we don't need to force everyone to manually micromanage and do things they hate to their posts in order to make them findable. – Darius Jahandarie Mar 9 at 3:25
How about making the search engine search for unknown words (those words which are not in the dictionary) with かな as well? jisho.org has such a function. – user1205935 Mar 9 at 11:42
1  
From a technical perspective, the lack of a one-to-one relationship between kana and romaji means it's very difficult (and not realistic at a large scale) to support on-the-fly querying of all variations... A possible compromise might be to give blanket authorisation to other members to edit posts with romaji-only with at least furigana. – Dave Mar 9 at 14:04
Do not forget that 室 is normally read as むろ (muro) by itself. – Dono Mar 9 at 16:09
@Dono That's a good point. In this case, I chose しつ because the reading was specified in the question body, though it wasn't specified in the question title itself. – snailboat Mar 9 at 21:23
1  
I don't think that's a major issue (in this case at least) as Google highlights the entire phrase of our article whether you search for "へや and むろ" or "へや and しつ", which would probably mean that Google indexes (or synonymizes) 室 as しつ as well as むろ. I think this also indicates how the Kanji+Kana distinction is less important than [Kanji/Kana]+Romaji – cypher Mar 9 at 22:36
I'm not that knowledgeable about webpage design, but as far as I can tell JLU web pages do not include Meta element tags, for example <meta name="keywords" content="taberu,たべる,食" >. That way, if there was a field in a question page to enter such keywords, it could be done in the background (not displayed), and be available for search engine use. If the main issue is to get the romaji user to JLU, this would eliminate the need for adding romaji (that as mentioned serious language students are unlikely to use) to the question and answer. And maybe add a romaji/kana reference page to help them? – user3169 Apr 4 at 21:59
@user3169 If it's not displayed, Google ignores it. If it's not displayed prominently, Google doesn't pay much attention to it. (Otherwise, keyword spammers would have overrun Google years ago. Sad, but true.) – snailboat Apr 4 at 21:59
Meaning Google search does not read meta keyword tags? I thought that was the point to having them. No wonder so many searches turn up garbage. Then again, maybe I am just not up to date... – user3169 Apr 4 at 22:02
@user3169 Matt Cutts at Google posted publicly about this in 2002. You can find a more recent post on the same subject here: mattcutts.com/blog/keywords-meta-tag-in-web-search – snailboat Apr 4 at 22:05
@snailplane Thanks, seems I am behind the times. I'll leave it to the experts. – user3169 Apr 4 at 23:39
Ironically... this page is currently the top result for one of your "nowhere to be found" examples. – jkerian Apr 18 at 20:36

1 Answer

The popular-question badge is awarded for questions which have 1000 or more views. If you go through the questions in that list, I've observed what could be a problem: out of those 47 questions (at the time of writing this), 25 have Japanese phrases or words in the title. Out of those 25 articles:

  • None of them use Furigana in the title
  • 15 have Romaji in the title
  • 17 have Romaji in the title and/or question
  • 21 have Romaji in the title, question and/or answers.

It could be argued that those figures have some issues, for example many of the questions were asked early on in this site's history, however I think there've also been many questions which don't have Romaji or used Furigana from reasonably early on, and as far as I can tell, for the most part they seem to be (relatively speaking) much less likely to be in that list.


I believe that a solution could be to rewrite the Furigana engine so that it helps, rather than harms SEO (Search Engine Optimization), and use Romaji. But at the same time I believe that preferably, the way which the content is displayed to the user should stay as close to what we have now, with as minimal changes as possible to the way people's questions and answers look. Therefore I would propose:

  • There should be a Romaji to Hiragana/Katakana conversion written in JavaScript for Furigana, e.g.:

    一人{hitori} will display as 一人{ひとり}

    Capitals will indicate Katakana, e.g.:

    鮫{SAME} will display as 鮫{サメ}

    It will likely use an input table similar or the same as the one used by Google's mozc IME engine.

  • The Furigana and words should be written in full so that Google can properly index the text. What we have now, e.g. 明​{あ}かす confuses Google, so it will be written as 明かす​{akasu}.

    Because 〜かす is the same in both Furigana and the original word there, it can be omitted, giving the same output (e.g. 明{あ}かす) as the previous way did.

  • There will be another syntax added, double braces (e.g. 漢字{{kanji}}) to allow adding Romaji for SEO purposes while not displaying as Furigana so that the original author's posts' appearance doesn't have to change while showing the information to Google. There could be an option, by default turned off to display these added to the Furigana for people who want it however.

  • There should be a way to input different Romaji transcriptions if necessary, e.g. おはようございます{ohayou gozaimasu, ohayoo gozaimasu}. Spaces written inside Romaji will be ignored to allow for cases like the above (as "ohayou gozaimasu" I think would be much more common than "ohayougozaimasu"). Note that only the first transcription will be used by the Furigana engine to convert to Kana.

  • It also should be as backwards compatible as possible with the previous Furigana system, so Kana in older articles and all of the previous 漢字​【かな】 etc syntaxes will still be supported.

  • This could also be an opportunity to fix some existing bugs and problems in the existing Furigana system, including font size issues (it may pay to make it larger by default and add a choice of font size, as well as maybe providing the option for popups or brackets, but I think Furigana displayed similar to as it is should stay the default).

    We could also add the LR notation for pitch accent as suggested by snailplane, as well as fix the bug where 犬が好​{す}き is displayed as 犬が好{す}き instead of 犬が[好]{す}き.

It would require updating articles for there to be benefits SEO-wise, so if this is decided on it may pay to start on a smaller number of articles and monitor their performance before rolling it out to a larger number.

I'm not going to be implementing this right away pending feedback etc, but I do think that there is a need for an overhaul of the Furigana system (one way or the other) and that it's been long overdue.

share
Do people actually know where the bar key is for ō? I'd think they would just use ohayoo or ohayou instead, depending on what their textbook uses. – Troyen Mar 14 at 5:11
@Troyen thanks, I think you're probably right, so I've changed it to "ohayoo" instead - I was trying to come up with an example where someone would want to transcribe in multiple ways but was having trouble. Most of the time I'd imagine people would use Hepburn similar to how an IME works (I think normally using "shi" instead of "si" etc), but I don't know because my textbooks didn't use Romaji. (As a side note, now I come to think about it I'm pretty sure Google actually indexes regardless of accents too, so if you typed in "ohayo" it might well find ohayō). – cypher Mar 14 at 6:29
I know Google suggests romaji when you search for rōmaji, and in some queries it assumes it was a typo and substitutes without asking, but it doesn't treat the two as synonyms, so searches for romaji don't match rōmaji. – snailboat Mar 14 at 6:56
hmm interesting - actually "rōmaji" and "romaji" come up with very different results for me on Google, and doesn't suggest "romaji" for me when I type "rōmaji". I think exactly which additional transcription systems we'd use would need to be a separate post on meta, but additional transcription systems past the first (as the above spec is currently written anyway) could be anything as it'll just be ignored at a JavaScript level, so I think it could always be changed later without changing any code. – cypher Mar 14 at 7:27
2  
I think might be an idea to just not use accents though, as I doubt a majority of people searching via Romaji would be using macrons or even less likely circumflexes as they wouldn't know how to input them as Troyen said – cypher Mar 14 at 7:45
...or because they are too lazy to type them. ;) – Troyen Mar 14 at 8:22
2  
To this day, if I need to type a macron, I copy and paste it from Wikipedia. :-) – snailboat Mar 14 at 8:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged