cocoaforge

Posted: **Tue Apr 05, 2005 5:30 pm**

アイドリング is quite interesting, but will people make the connection?

Posted: **Tue Apr 05, 2005 6:53 pm**

Which (English) string is possibly having an improper code-side addition of "…"?

Posted: **Wed Apr 06, 2005 1:34 am**

ickoonite wrote:I've been meaning to raise this issue for a while. It happens in a lot of Mac OS X localisations. The problem is that the Mac has a character, presumably within the ASCII set, for "...". When the system locale is set to a Western encoding, this comes up fine. But if you switch to, say, the Japanese encoding, that character is instead a half-width katakana ノ. If there is specific code in Adium which appends the "...", it really needs to append three full stops, rather than the special all-in-one symbol, for compatibility's sake. It may well be that other non-Roman localisations will be similarly affected.

Alternatively, it may just be an oversight in the Localisations source file itself, simply requiring a replacement of what looks like three full stops with three actual full stops. Or should I say periods?

I don't think we need to use three periods/full stops instead of an ellipsis. As you can see in my screenshot, "toolbar no custom" ends in an ellipsis without a problem, as do a lot of other menus. I will say that this is pretty persistant problem in OS X. There are a lot of apps that have problems with ellipsis and Japanese localization. I think Apple needs to make sure that the next version of Interface Builder requires developers to explicitly declare the character set, instead of just using whatever the system default is. Or maybe they should a better job of guessing that programs that only have a an English .lproj should be decoded in the Mac character set…

Posted: **Wed Apr 06, 2005 1:17 pm**

evands wrote:Which (English) string is possibly having an improper code-side addition of "…"?

Got it - at last! I was hacking around with this for a while, but I see what's going on now.

The Localization.strings file has only one entry for "Configure Status Sort". That string is used for the title of the floating window that comes up, and for the menu entry, where the troublesome "..." is added. There is, in fact, a slight difference in the way OS X renders three separate full stops and the three dots character (the former is slightly heavier), but it shouldn't trouble anyone.

I just added you on my AIM account - if any further clarification or debugging is required (I am building from SVN anyway), perhaps that would be quicker.

Posted: **Wed Apr 06, 2005 1:42 pm**

im so jeasous!!!

i also want to speak japanese.
japan is soo cool!

Posted: **Wed Apr 06, 2005 1:58 pm**

Some (most, perhaps) of these stem from inconsistencies in and weaknesses of the original English...

In the File menu, we have 新規チャット (New Chat), but the message box that comes up is entitled New Message, as yet untranslated, presumably as it has not yet had the necessary code modifications applied. There needs to be consistency here.

It should be ツールバーをカスタマイズ, not ツールバーのカスタム.

Is there a reason for having アルファベット順にメンバーを並べる but メンバーを状態によって並べ替える?

In メンバー名のフォーマット, we have エイリアス（スクリーンネーム), but in the tooltips (or floaty contact info thingummies - whatever they are called), we have ディスプレイ名.

I'm confused by メンバーを追加 but グループの追加 in the メンバー menu, but I wonder if this is just "the way it is" in Japanese.

Isn't 前の会話を表示 just hideously cumbersome, even if it is an accurate translation of the English? Wouldn't 履歴（を表示）be more concise?

I'm being truly pedantic, but then that's what I do - in the アドレスブック section of 詳細環境設定, there is the 名前のフォーマット drop-down combo box. In it, we have 名　姓, but 姓名 (i.e. Japanese full width space vs. half width one).

In the メンバーリスト (Contact List) section of 詳細環境設定 (Advanced), under ツールチップ (Tooltips) there is "Adiumが背後にあるとき". The original English is bad in this one, but (and Evan, correct me if I'm wrong on this) I interpreted it to mean "Even when Adium is in the background," hence my original "Adium は手前のウインドウではない場合にも表示". If my French hasn't failed me totally, the French translation would appear to agree with my interpretation.
In any event, the current string needs a space after the word Adium.

Posted: **Wed Apr 06, 2005 3:26 pm**

ickoonite wrote:The Localization.strings file has only one entry for "Configure Status Sort". That string is used for the title of the floating window that comes up, and for the menu entry, where the troublesome "..." is added. There is, in fact, a slight difference in the way OS X renders three separate full stops and the three dots character (the former is slightly heavier), but it shouldn't trouble anyone.

Ah, but we're going for perfection!

Configure Status Sort was one of the holders-on from when we were hardcoding … (the single character version) rather than using the proper unicode escape sequence so as to be localization-independent. Fixed it... if you see the same problem anywhere else, please submit a patch to do the same -

Code: Select all

[AILocalizedString(@"Configure Status Sort",nil) stringByAppendingEllipsis]

is the proper formulation.

I just added you on my AIM account - if any further clarification or debugging is required (I am building from SVN anyway), perhaps that would be quicker.

Cool, will be online later today.

Posted: **Wed Apr 13, 2005 9:35 pm**

So I've been messing around with the Localization Manager, and that's all cool, but do you know why the contents inside Localizable.strings turn out encoded, and how I could decode to read it normally? I tried opening the text as various encodings, but didn't get anywhere. Opening as UTF-16 even crashed my text editors. I know I should just be looking at the .ldb file but I was curious.

Posted: **Thu Apr 14, 2005 2:34 am**

I had the same problem, and it was the reason I rolled my own translation originally. I'd almost label it a Localizer bug - that it insists on escaping every character so that it becomes essentially uneditable - really it ought to generate files with normally encoded characters in the standard encoding, which I presume to be one of the Unicodes (i.e. either UTF-8 or -16).

Posted: **Thu Apr 14, 2005 3:17 am**

ickoonite wrote:I had the same problem, and it was the reason I rolled my own translation originally. I'd almost label it a Localizer bug - that it insists on escaping every character so that it becomes essentially uneditable - really it ought to generate files with normally encoded characters in the standard encoding, which I presume to be one of the Unicodes (i.e. either UTF-8 or -16).

Use UTF-8 please. Yeah, it's uneditable. I hate that.

Posted: **Thu Apr 14, 2005 4:49 am**

ickoonite wrote:I had the same problem, and it was the reason I rolled my own translation originally. I'd almost label it a Localizer bug - that it insists on escaping every character so that it becomes essentially uneditable - really it ought to generate files with normally encoded characters in the standard encoding, which I presume to be one of the Unicodes (i.e. either UTF-8 or -16).

I've filed a request for them to be written in unicode, but I'm not even sure _how_ to write it as such... writing it out in the unicode encoding performs that escaping apparently.

Posted: **Thu Apr 14, 2005 4:54 am**

Thanks for taking notice!

Also, where should I start looking if I wanted to create more 'hooks' in the actual source to handle more localizable.strings? I could probably learn by example if I could see one.. (I got the source downloaded from svn.. just a nooB when it comes to the Cocoa framework). Thanks!

Posted: **Thu Apr 14, 2005 5:29 am**

macyu wrote:Thanks for taking notice!

Also, where should I start looking if I wanted to create more 'hooks' in the actual source to handle more localizable.strings? I could probably learn by example if I could see one.. (I got the source downloaded from svn.. just a nooB when it comes to the Cocoa framework). Thanks!

I'm not aware of any missing hooks besides some .nib files which are not marked translatable yet even though they should be because they are going to be changing soon or such... so the best thing to do at present is point out anything you find that should be translatable but isn't.

Posted: **Thu Apr 14, 2005 2:57 pm**

evands wrote:I've filed a request for them to be written in unicode, but I'm not even sure _how_ to write it as such... writing it out in the unicode encoding performs that escaping apparently.

That is weird. The only wisdom I can lend to it is that the escaping looks like something I used to see in HTML files. Normally when you edit an HTML file these days with Japanese in it, you just save it in Unicode and if there is any escaping or encoding, it is transparently done, but I seem to remember that, say, if you wanted Unicode-encoded characters in a file which was otherwise Western-encoded (perhaps? This is a bit of a guess...), such escaping would occur in a manner similar to & (i.e. ampersand-amp-semicolon).

I can only presume the save routine for the application is slightly borked, although what is odd is the issue of why it is interpreted correctly by the OS for display purposes (i.e. in the application) but not for editing.

Posted: **Thu Apr 14, 2005 3:04 pm**

ickoonite wrote:I can only presume the save routine for the application is slightly borked

Only in the sense that you're expecting the Localizable.strings file to be editable... the application isn't too concerned because it expects that if you're using Localization Manager at all it's what you're using for all translations of strings.

Of course, since I'm sitting around waiting for the developer to fix a major bug which is preventing us from continuing right now, that assumption is a bit problematic. It'll get resolved... just sucks putting everything related to translation on temporary hold.

although what is odd is the issue of why it is interpreted correctly by the OS for display purposes (i.e. in the application) but not for editing.

Nothing odd about that at all... those are standard unicode escape sequences, interpreted as the unicode character in question with within an unescaped string literal.

Posted: **Thu Apr 14, 2005 3:23 pm**

evands wrote:Only in the sense that you're expecting the Localizable.strings file to be editable... the application isn't too concerned because it expects that if you're using Localization Manager at all it's what you're using for all translations of strings.

Yeah, fair point. And, to be honest, I suppose the .strings files don't really want/need editing, seeing as the changes can't actually flow upstream anyway.

evands wrote:Of course, since I'm sitting around waiting for the developer to fix a major bug which is preventing us from continuing right now, that assumption is a bit problematic. It'll get resolved... just sucks putting everything related to translation on temporary hold.

That's what we get for living on the edge, using beta software, etc.!

Posted: **Thu Apr 14, 2005 4:40 pm**

ickoonite wrote:That's what we get for living on the edge, using beta software, etc.!

Oh yeah

If you ain't livin' on the edge, you just ain't livin'.

Posted: **Sun Apr 17, 2005 12:03 am**

Just on another note… I wanted to do SOME Japanese Translation unrelated to software projects, so I am doing one for Fire…

Heh, anyone want to help? I would doubt it since it's an Adiuum forum

The thing is, Fire has MANY translations that need to be done, more than Adium does.

Posted: **Thu Apr 21, 2005 2:48 am**

I've been tackling the Gaim Service translations, and I have some questions. Since I'm haven't encountered these strings, I didn't know in which context they existed or what technologies the strings refered to. The ones I need clarification are:
Balancer handshake
Import Sametime List...
'load and save' option (presumably for the contact list)
GG Number
Roster

and also the context of the 'Yes' and 'No' strings in the gaim plugin strings

Thanks!

Posted: **Thu Apr 21, 2005 8:40 am**

macyu wrote:Balancer handshake

Not actually displayed, translated for possible future expansion.. it's a step in some protocol's connection sequence. Can safely be left in English.

Import Sametime List...

Import a contact list for the Sametime protocol. It's a menu item.

'load and save' option (presumably for the contact list)

Also sametime... Might want to take a look at the Sametime account preferences. "load and save" refers to how the client interacts with the server's contact list

GG Number

Gadu-Gadu Number... like "Screenname" or "Jabber ID"

Roster

A default name for the Jabber buddy list

and also the context of the 'Yes' and 'No' strings in the gaim plugin strings

Not sure

Probably buttons responding to a dialogue.

cocoaforge

Japanese translation

A Few More Corrections and Inconsistencies

Questions on the gaim service strings

Re: Questions on the gaim service strings