User talk:Furrykef

I was thinking it would be helpful to show/hide furigana for templates with reading. This way, you could by default hide furigana and only show them if you are unsure about the reading. This site [1] seems to have an easy way of adding hide/show, but it requires a change to Common.js which I do not have access to. Or pehaps it is already possible and I do not know how? What do you think? Blutorange 19:50, 3 January 2011 (UTC)

I've had that idea too. I might get around to it soon, but I've been extremely busy lately... - furrykef (Talk at me) 14:04, 4 January 2011 (UTC)

Hymmnos-Reading

Did you have the Hymmnos font installed (see link at template)? It should look like this: Or do you think displaying the original script is not a good idea? Blutorange 09:23, 8 January 2011 (UTC)

Sorry, my mistake. - furrykef (Talk at me) 09:36, 8 January 2011 (UTC)

Voice Clips

Do you know how the legal situation is with uploading voice clips from games here and would you even want that (server costs, ...)? Blutorange 09:37, 21 January 2011 (UTC)

Voice clips are fine with me, though it'd certainly be easier to avoid legal trouble with older games than with ones that have just come out. I'd really love to get the clips from Star Fox 64, for instance, but, alas, I have almost no idea how to rip them. - furrykef (Talk at me) 09:44, 21 January 2011 (UTC)

It's possible without "hard ripping" http://www.megaupload.com/?d=G5PRJ0GG :) Although it requires triggering each voice you want to record in-game... If the voice clips are to be hosted on the wiki, you will need to allow an audio format for file uploading on the wiki (currently only images are allowed). For playing the audio, the easiest way would be too use <embedded> html syntax, or perhaps implement an audio player plugin on the wiki...? Blutorange 14:43, 21 January 2011 (UTC)

I've added html rendering to my script and the result looks like this: http://img706.imageshack.us/f/japaneseexample.png/ . The voice clips are implemented with a few lines of javascript, the onmouse-furigana simply use the tag. Implementing this in the wiki should be easy. I think this is the tidiest of of showing the readings, and it also forces you to try to remember how the kanji. Optionally, it would be easy to add some button to trigger showing only kana (and kanji on mouseover?).

The javascript for supporting voice is this:

function DHTMLSound(surl) {
     document.getElementById("dummyspan").innerHTML=
     "<embed src=\'"+surl+"\' hidden=true autostart=true loop=false>";
     }

This works much better than <embed> and doesn't crash the browser.

You would then use it like this:

<span id=dummyspan></span>
     <form>
     <input type="button" value="Voice" onClick="DHTMLSound(\'' .. voicefile .. '\')">
     </form>

Move the mouse over this text.

Blutorange 23:37, 21 January 2011 (UTC)

I still don't know if I like the furigana idea. Furigana like that would be a mess to edit, and quizzing yourself on the reading was never really the intended purpose. As for the voice clip stuff, maybe, but I'm busy with many other things at the moment, so I'm probably only going to concern myself with basic wiki administration for a while... - furrykef (Talk at me) 06:30, 24 January 2011 (UTC)

Provided the reader understands a fair amount of kanji used in the game, leaving out the reading line makes the whole text shorter and so it may actually be easier to read. Also, if one wants to look up furigana, locating the reading in one big line of kana may be harder than moving the mouse over the the unknown kanji. Anyway, I think we should leave it to the reader to decide how to display the information. As for implementation, if the reading for each kanji word is known, it is easy to format the whole line once in kanji and once in only-kana. As for editing, I'm currently writing my text with an IME using a modified dictionary, so that "かんじ" converts +感<かん>じ or +漢字<かんじ>, thus making it ridicolous easy to provide furigana for each word. I then parse this to produce wiki syntax. Syntax such as +感<かん>じ is definitely easier to edit than, say , but I was thinking one could make this even easier by making just a slight change to the template, eg:

{{jp-r-en|「振仮名」とは、漢字又は外来語の上に発音を示す仮名。|「　ふりがな　」　とは、　かんじ　また　は　がいらいご　の　うえ　に　はつおん　を　しめ　す　かな　。」 | Furigana are characters above kanji or foreign words displaying the pronunciation.}}

is easy to read an edit in the wiki, and can easily be parsed by javascript with

  var array_kanji = kanji.split("　")
  var array_furigana = furigana.split("　")
  if (array_kanji.length == array_furigana.length  and  user_wants_it_like_this == true) {
     document.write( span title=furigana[0] kanji[0] ... ) }
  else {
     document.write( kanji | furigana ...) }

This way it's also quite error proof, when the furigana don't match you can just fall back to the current style, and it would preserve backwards compatibility with the current syntax. You could also add an optional argument to the template plain_reading = (default)true you would have to explicitly set it to true, avoiding coincidental matches in the amount of spaces. Blutorange 15:27, 24 January 2011 (UTC)

And here's a working demo of how this might look: [2] or [3]. Note that this is on my home pc, so links may not work when I'm offline.

Discussion with Jcdietz03

Please check out LLTVG:Sandbox for an idea for parallel-text. There is probably a better way to implement this, as I am not a programmer. If you need more info on parallel-text, please check the other wiki (though it is admittedly a bit sparse). You can check out some ja-en parallel text books here to see what they look like. I dislike looking up/down to see parallel text and prefer left/right. It is simply my preference. I am not sure about conventions used in parallel-text works, so I cannot say which convention is more commonly used. I just finished reading Understanding Basic Japanese Grammar which uses parallel text almost exclusively as the method of instruction. Parallel text in this book uses the left-right convention.

You commented that my translated text blocks are too large. This is not in the guideline. Also, I disagree with this as a proposed guideline. When one character is talking at length, it's appropriate to have a huge block of text. I don't think it's appropriate for conversations as it is difficult to tell who is talking. If your knowledge of Japanese is sufficient, you just want to read the text and the wiki markup gets in the way of that. If your knowledge of Japanese is not sufficient, you want to refer to the translation. I think left-right parallel-text (instead of up-down) will make this type of reference easier for readers but harder for editors.

You commented that I excessively use the br tag. Guilty as charged. However, this is not in the guideline. The guideline I use when editing is that one screen of dialogue (up to three lines) per one line in the wiki. I use the current guideline as well (use br tag if a sentence ended without punctuation). The other guideline I use is that if the writer couldn't quite fit what they were trying to say into three lines, I include the extra in the previous line. Jcdietz03 21:15, 20 April 2011 (UTC)