SCIM help dialogue for scim-skk is in Japanese

I see this bug is still present in Gutsy.

I'm going to attach a dpatch patchfile which fixes this. (ie a file you can dump in debian/patches and add to the debian/patches/00list). This patch is against scim-skk 0.5.2-5.

This patch essentially just gettext-izes the help text. The existing Japanese help message is moved unchanged into the ja.po. The English help message is a translation from the Japanese; I believe it to be accurate but may of course have made mistakes. It could probably be more helpful, but I chose to stick to a fairly straight translation rather than trying to improve on it as I went along.

This is my first run-in with the gettext machinery, so it's possible I may have got something wrong. However I have checked that the help text displays the Japanese text in a Japanese locale (ja_JP.UTF-8) and the English text in a UK locale (en_GB.UTF-8) so it all seems to work.

I have copied the URL unchanged from the Japanese help to the English; this is no loss because the URL is a 404 anyway :-) This probably ought to be fixed but that would involve finding a proper description of the input mode in both Japanese and English and referring to it instead. Or such a longer description could go in the help text instead of the current quick-reference information. Either way, I think that's out of the scope of this bug.

You will note that the initial size of the help dialog box is such that bits of the text are cut off on the right hand side. This looks to me like a programming bug -- the dialog box is sized to fit the text except that no account has been taken of the need to allow space for the scrollbar. The Japanese help text has the same problem although by some fluke it only affects a single line of text and that not very badly. Anyway, I think that's a separate issue (for which I have not filed a bug report).

Hope this helps!

Oh yeah, and the version number quoted in the help is way out of date; I didn't change that either.

To get your fix included in Ubuntu, try transforming it into a debdiff (http://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff) and submitting it for review (http://wiki.ubuntu.com/SponsorshipProcess).

This shouldn't be Incomplete; there's no reason for it to be expired just because the patch is in a different format. (Were I the maintainer, a dpatch to an existing dpatched package would be straightforward to deal with. I think Daniel is trying to get you more involved in the Ubuntu development process, for which providing things in a standard form where a sponsor who isn't necessarily an expert in the package in question can deal with it can help matters.)

The gettextisation looks functional, but is a bit suboptimal. Normally, one arranges for a paragraph at a time to be passed to gettext. Passing a huge wodge of text like this means that if the help message ever changes then the whole thing becomes fuzzy and has to be retranslated into all supported languages. (May or may not be a practical issue here, but still.) The usual sensible unit of text to translate is a sentence, although in this type of text I think a paragraph would be fine. This would also let you leave things like the package name and version number at the top untranslated, which is probably more sensible.

Unfortunately it doesn't seem entirely trivial to do this, because the way that file is used expects the contents of scim_skk_help_message.txt to be a single expression. Do you think it would be straightforward enough to shuffle things around so that it can concatenate several strings instead?

And, indeed, if done well one could avoid the requirement for manual line breaking in every single translation, which is always going to be a pain; translators can't be guaranteed to actually fire up the application to see how the results look.

I also noticed that there's a rule in src/Makefile.am to regenerate the help file from some original source using an awk script, except that neither that source nor the awk script is in the source package. Perhaps somebody could check out upstream revision control (if available) and see if it's there? That might lead to an easier approach.

Upstream CVS should be http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/scim-imengine/scim-skk/ and the awk script and help message source file seem to be there.

I've reported this issue to upstream.

Is this something that still needs fixing in Karmic?

without further information, I will assume this is fixed. please reopen if you still have problems.

No, it's not fixed in Karmic.

(I personally think that requiring bug submitters to respond to 'please retest' pings is counterproductive; there are some arguments along these lines here: http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009/03/02)

Peter, thank you for responding now. You're entitled to your opinion, I don't need to agree.

And the link you posted is completely irrelevant here since I'm also the Debian Maintainer, so I *am* the dev that Collin is talking about and I *do* require bug submitters to not just "fire and forget". I ask for active cooperation if you want your bug fixed, if you like it or not. And the most basic information is if the bug is still present or not.

I don't think a long list of open tickets that nobody feels like working on is better than a short list that somebody is indeed trying to fix.

I just released a new scim package in Debian, but I don't expect any changes as far as bugs are concerned for Ubuntu. I also took the chance to push all those patches upstream (oh, yes, I do have commit rights in the upstream scim project, too). So, if you want to say "do you your homework", I would respond that *you* need to do it. You're barking up the wrong tree.

A bug's status is easy enough to change, anyways.

Thank you for the patch, it would have likely been in the current release if you just hadn't ignored the ping.

looking more closely myself, I'm not sure what motivated me to get involved with this bug. I was apparently mistakenly assuming that scim-skk was a derived package from the scim src package which is not the case. The package seems to be in pretty bad shape in Debian. I can't properly compare scim-skk and scim-anthy as I've never used the former. But the latter package is still being worked on (by me, for example ;-)) So maybe you want to consider a switch to scim-anthy or even ibus-anthy.

removing myself from cc, I can't and won't fix this issue. My apologies.