OK. I've scored my first game, and these are the i18n problems that I've faced:
Step 1: Give the two teams names in Japanese (横浜 vs. 巨人).
Step 2: Fill the rosters with players with names in Japanese.
Step 3: Score a game.
Up until here, everything works fine. The Kanji really look good and crisp on the green background.
Step 4: Select Game Manager from the main menu.
Step 5: Select <date> 横浜 at 巨人.
Here the line score at the top has the team names as iso-8859-1 characters, not UTF-8 characters. So they look like accented and special characters (like the Registered Trademark symbol). These aren't readable.
Step 6: E-mail all game reports to self.
The message header had the 浜 in 横浜 escaped or something as it failed to come out properly. The other Japanese characters seemed to come out OK.
The HTML and CSV files all come out fine using UTF-8 encoding.
However, the PDF and XSL files both appear to use iso-8859-1 character set for their base encoding, causing none of the Japanese names to be readable.
Regarding the XSL file, NeoOffice (an OpenOffice clone on Macs) tried to open the file as a text-based spreadsheet. Renaming the extension to .xslx still failed. What is the Excel version that this file should correspond to?
I've generated ODF spreadsheet files Mixing Japanese, Korean, and Traditional Chinese characters all in the same documents with no problem as ODF defaults to UTF-8 encoding. Previous experience with Excel seemed to indicate that it could only handle one region-specific encoding at a time, so I'm not sure about that format's viability in a multi-language environment.
---
While scoring, I found the Strikes indicator in red to be confusing. It's probably due to watching so many games in Japan where the indicator is usually displayed:
Strikes ●●
Balls ●●●
Outs ●●
So every time I'd see two strikes in the upper-right corner, I'd think there were two outs. I realize that Japan does balls and strikes backwards, but the color has as much impact as the location. (If it were possible to select reversing the order for balls and strikes as an option, that too would be good.)
Overall, it was very easy to use, I'm impressed. Having rosters pre-entered would definitely help as I was trying to enter players as the game was going on. (The videos made it look possible, but that was the one and only difficult aspect of the game entry.) If I could just enter a player's uniform number or name by double-tapping the auto-generated "Player 5" or something on the substitutions dialog, that would have been tremendously helpful.
Well, that's a wrap on the first attempt and problems encountered. Hope it helps, and I look forward to the software evolving.
Internationalization
-
- Posts: 4
- Joined: Sun Aug 30, 2009 6:08 pm
- Location: Yokohama, Japan
- FTMSupport
- Site Admin
- Posts: 13193
- Joined: Sat Mar 28, 2009 7:25 pm
Re: Internationalization
Thank you for the feedback on i18n issues. We do plan to eventually localize iScore to different regions, and would address things like this at that time. We have had offers to translate to both Spanish and Japanese --- we just need to take the time to break all text display into resource files to allow this. We have been focusing more on functionality, but will eventually get to the point that i18n / l10n become a higher priority.
Thank you again.
Thank you again.
-
- Posts: 4
- Joined: Sun Aug 30, 2009 6:08 pm
- Location: Yokohama, Japan
Re: Internationalization
Perhaps I put too much in there. How about these three requests:
1. Have strikes indicated in yellow instead of red.
I'm not aware of MLB standardizing on colors for balls, strikes, and outs, but Japan is really good at standardizing on colors for everything.
2. Allow quick name/number settings while the game is going on.
Rather than selecting Misc --> Edit Starting Lineup, tap the batter or position as though to change the batter/fielder, but allow the player to be double tapped or other gesture to edit. Even being able to edit the name right there would be a big help.
3. Output to ODF spreadsheet (ODS).
Just by using ODF for output instead of XSL you get i18n issues resolved. I fear that you'll have to find strange work arounds to get i18n to work properly for the Excel format. I understand that ODF output would be a new task unto itself, so I guess this should be marked as a long term enhancement.
1. Have strikes indicated in yellow instead of red.
I'm not aware of MLB standardizing on colors for balls, strikes, and outs, but Japan is really good at standardizing on colors for everything.
2. Allow quick name/number settings while the game is going on.
Rather than selecting Misc --> Edit Starting Lineup, tap the batter or position as though to change the batter/fielder, but allow the player to be double tapped or other gesture to edit. Even being able to edit the name right there would be a big help.
3. Output to ODF spreadsheet (ODS).
Just by using ODF for output instead of XSL you get i18n issues resolved. I fear that you'll have to find strange work arounds to get i18n to work properly for the Excel format. I understand that ODF output would be a new task unto itself, so I guess this should be marked as a long term enhancement.
- FTMSupport
- Site Admin
- Posts: 13193
- Joined: Sat Mar 28, 2009 7:25 pm
Re: Internationalization
For #1 - We do not color code outs with the lights the way we do with balls and strikes. There is no standard we have ever found or we would have followed it, but being that we only color code balls and strikes, the green/red method we used makes sense to us. Using yellow and green are two colors that are pretty close together and at first glance would not be obvious to distinguish. We will be adding "preferences" in future releases which will allow users to customize various things about the system --- maybe color of balls/strikes will be one of those. Keep in mind we have kept consistency throughout with iScorecast as well however, so that would mean changes there also.
For #2 - This is a good idea, and we will work on ways to make editing names on the fly easier in a future release.
For #3 - We added CSV output to version 2.0 to avoid compatibility issues (and even i18n issues in this case). The CSV format should be compatible with any spreadsheet program, and this way we no longer have to worry about peculiarities of different formats (even the Excel format we use was not compatible with all versions of Excel, so we are trying to avoid any specific formats going forward as much as possible).
Thank you again for the suggestions.
For #2 - This is a good idea, and we will work on ways to make editing names on the fly easier in a future release.
For #3 - We added CSV output to version 2.0 to avoid compatibility issues (and even i18n issues in this case). The CSV format should be compatible with any spreadsheet program, and this way we no longer have to worry about peculiarities of different formats (even the Excel format we use was not compatible with all versions of Excel, so we are trying to avoid any specific formats going forward as much as possible).
Thank you again for the suggestions.