Moyo Go Studio translation done etc
BOAB naming convention - 4:13 PM 7/3/2006
Since the “BOAB”, “Another BOAB”, “Yet another BOAB” naming scheme sucks, I decided to change the naming scheme. The naming scheme will be “[The most insteresting BOAB] etc”, for example “I won a 10 million lottery etc”
Moyo Go Studio translation done - 3:30 PM 7/3/2006
I think the translation (784 strings) has passed sufficient quality control to be released to the wild. Some translation and naming issues that were brought to light:
- How should menu items be capitalized? “Add Games”, “Add games”, “add games”, or, God forbid, “ADD GAMES”? I chose to capitalize the start of every word, except for some particles like “and”. The English strings aren’t consistent in this matter (for example “Add games” vs. “Save Board Capture As”).
- Which brings us to the next question: What words are immune to capitalization? “and”, “or”, “in”, “on”… What else? I chose to not capitalize “not” (”tidak”). Is it appropriate? There must be a guideline somewhere…
- If a menu item contains an explanation in parentheses, how should it be capitalized? An example is “Result (fast, inaccurate)”. I chose to capitalize the explanation also. Is it overcapitalizing?
- What is the criteria to give ellipsis (…) to a menu item? I read on a usability article somewhere that ellipsis should be used on a menu item that prompts the user for more information before being able to execute the intended action. For example, “Save As…” should use ellipsis because the program will prompt the user for the file name before being able to save. “About” shouldn’t use ellipsis because it directly does the intended action which is displaying the about dialog. I follow this guideline. Some English strings violate this guideline, for example “Search” and “About…”. (Almost every Windows program use ellipsis for the “About” menu item)
- A convention I don’t like is that the English strings append the ellipsis in the msgid. I prefer that the ellipsis be added at run time when building the UI. What problem does the current practise pose? Here’s one example: There is the msgid “Search”, which is used in the “Database” - “Search” menu. It really should be “Search…”, so I translated it as “Cari…”. It turns out that the msgid “Search” is used on places other than the menu (for example on the button on the dialog of “Database” - “Search”) and in those other places the ellipsis isn’t appropriate.
- How should one capitalize tooltips? “Back up and take other variation” or “Back Up and Take Other Variation”? I prefer to capitalize only the first letter of the first word.
- Should tooltips end with a dot? “Back up and take other variation” or “Back up and take other variation.”? Things get messy when a tooltip contain 2 sentences. I prefer to omit the dot for single-sentenced tooltips while use dots for multiple-sentenced tooltips. There are inconsistencies in the English Moyo Go Studio (For example “Move trough current variation.” vs. “Board perspective”).
- The translation of a single English word can be multiple words, in which the problem of capitalization arises again. For example, should “Handicap” be translated as “Batu bantu” or “Batu Bantu”? The translator must check where the string will be used to determine the correct capitalization (by running the program and hunting for the string). A serious problem occurs when the string is used in 2 places with different capitalization requirements.
With those problems, it is impossible to create an Indonesian translation that consistently adheres to a good UI naming guideline. Therefore, some compromises must be made. I chose to make the menu perfect even if that means inconsistencies on other places.
I’ll give an example of the inconsistency that arises. Menu capitalization dictates that it is “Langkah Baik”, not “Langkah baik”. Sadly, a tooltip uses the exact same string. Because tooltips are supposed to use a different capitalization rule, the tooltip violates the rule.
My idea is that words in the msgstr should be lowercased except for proper names (which starts with an uppercase), and then the program will call an appropriate method to build the final string. For example:
string menuString = MakeMenuString(GetString(msgid)); string tooltipString = MakeTooltipString(GetString(msgid));
An alternative is to have multiple msgids for the same word which is used in different places. For example:
msgid "menu-handicap" msgstr "Handicap" msgid "tooltip-handicap" msgstr "Handicap"
I envy languages without uppercase/lowercase mess, like Arabic, Japanese (カタカナはuppercaseじゃない), Korean, and Chinese.
I mentioned many inconsistencies of Moyo Go Studio’s English strings. However, I believe that string consistency is generally an underworked area in many other software projects. For example, Notepad++, the software I use to write this blog entry, also has many inconsistencies in its strings.
Other than string consistency (or the lack of), another area where Moyo Go Studio sucks is in its window layouting system. Widgets in its dialogs have fixed coordinate and size, so problems like this arise:
With the availability of toolkits like GTK, hardcoding coordinates and sizes is oh so outdated. It is as obsolete as hardcoding the time cycle of old games to clock frequecies (try playing Sonic 3 on a modern computer and you’ll see what I mean).
Moyo Go Studio sucks on at least one other thing: It can’t change language on run time (need to restart the program). Even my (+Wijaya and Karnan) LifeSimulator can do it :)! Hmm, as far as I remember, even SmartGo can do it 
(tried the time-limited trial version).
Wait, I found another area where MGS sucks: It doesn’t run on Linux (Frank stated clearly that he’s running a Windows software shop so no chance of this happening soon). It would be cool if MGS has a GUI-less server version mode or a library of its core with usage documentation (easier to port), so other people could write a Linux client.
How good is Moyo Go Studio as a Go Suite? I’ll probably write a full review some time in the future after I’ve become more familiar with the beast and if I have free time. My first impression is that it is a superb Go study tool lacking some UI polish. However don’t let this blog entry discourage you to buy MGS because the problems mentioned probably won’t bother your daily use and because it will certainly be fixed in the future (after the kickass tactical module project?). Moyo Go Studio is definitely worth your $$ (or time, if you plan to translate it)!
UPDATE: I told Frank about this blog entry. Some days later, on July 7, Frank released an update that adds an extra space to the problematic widgets. That workaround made my Indonesian translation look fine.
TK II done! - 12:27 PM 7/3/2006
At last I finished the TK II! I’ve given the report and CD to an Ilkom office staff which will hopefully be passed to Pak Medi.
My TK II was about making SharpJiten, a kanji dictionary written in C# which uses GTK# for the GUI and KANJIDIC for the dictionary. Here’s a screenshot:
Some last remarks:
- I can’t get GTK# for .NET working. Therefore I opted to bundle Mono in the CD.
- IconView is a terribly slow widget. Give it 200 items to draw and it will choke. A workaround is to divide the items into separate pages but I didn’t implement it.
A page, which contains SharpJiten’s description, installation method, source code, and TK II report can be found at http://agro.web.ugm.ac.id/sharpjiten.
Since the TK II is done, now I need to finish my other duty: translating Moyo Go Studio.
PS: One flaw in the hardcopy of the report is that page 12 and 13 is flipped!!!
Early month shopping - 9:12 PM 7/2/2006
Phenomenon: There are many people shopping early at the month (1st or 2nd day). Queues are extremely long.
Hypothesis: People just got their salary.
Explorer/Windows file name limitations - 10:17 PM 7/1/2006
In Windows Explorer, we can’t rename a file to “prn”, “con”, “com0″ - “com9″, “lpt0″ - “lpt9″, and only God knows what else. That’s because in the Windows world (which originated from the DOS world”, those names are special names used to address some devices. For example, “prn” refers to the printer (Which printer? Probably the primary one.) and “con” refers to the console. Turn on your printer (if you have any) and try this command:
copy con prn
You will effectively have a typewriter.
PS: How did I know it? Remembered it from my old DOS times… In those days, tricks like “copy con config.sys” is commonly cited.
That system itself is inferior to Linux. In Linux, devices are files in the /dev directory so you won’t have artificial file name limitations.
But if that’s the limitation of the lower system, I can accept that Explorer don’t allow it. However, what’s confusing is that Explorer won’t give any explanation for this behavior. Instead, when renaming files to one of those names, it will set the file to the previous name.
Next case. NTFS and FAT32 support file names that start with a dot (for example “.bashrc”). As a proof, try:
echo > .test
And a file with the name “.test” will appear.
However, try making a file in Explorer that starts with a dot and Explorer will say “You must type a file name”. Silly.
Another one. NTFS and FAT32 also support file names that start with a space (for example ” foo”), as long as it is followed by a non-space character. As a proof, try:
echo > " foo"
However, when renaming files using Explorer, it will remove the leading space.
I don’t know whether this is the limitation of NTFS and FAT32, but I can’t find a way to make file names that ends with a dot (like “crhsab.”) and file names that ends with a space (like “foo “).
I’ll test all those in ext3. As an evil hack, I’ll try creating the illegal files on a FAT32 partition under Linux >:).
