[etoys-dev] eToys i18n analysis and suggestions
cjlhomeaddress at gmail.com
Fri Jun 17 09:51:31 EDT 2011
Dear eToys devs,
Attached please find a comprehensive (but not necessarily complete)
analysis of opportunities to make internationalization improvements in
the eToys UI strings. I cannot guarantee that every comment made will
(or should) result in changes, but I do believe that they all deserve
Note: I originally tried to send with attachment, but it was too
large for list filters. The spreadsheet can be found attached to this
In the attached spreadsheet.
Column A is an overall sequential number of the strings, PO files are
in alphabetical order. Sort on Column A to put them back in their
original order in the PO files
Column B are my comments. The numbers in Column B are simply to group
strings that should be considered together. Sort on Column B to group
together similar strings to consider merging.
Column C is the filename of the originating PO file.
Column D is the location string from the PO file.
Column E is the strings themselves. Sort on Column E to look for more
opportunities to merge strings
Further explanation of my brief comments:
The annotation "merge" in this context means that these strings are
similar enough that it might be possible to harmonize them to a single
spelling/format. Making these changes will result in fewer strings
only in the cases where the variants occur in the same PO file
(typically DrGeo), but it should also result in producing a more
useful terminology PO file for eToys.
This may seem trivial until you realize that (quit, Quit, QUIT and
Quit:) all count as different strings to Pootle and to poterminilogy.
This can multiply the number of strings for a localizer to translate
and result in missed opportunities to include a common term in the
The note "long, break up" suggests that this string might be easier
for locaizers to handle if it were parsed into smaller consecutive
strings rather than one long string. Yes, this will create more
strings, not fewer, but they will be easier for locaizers to work
The note "caps x" and "caps y" point out inconsistency in capitalizing
the X or Y in strings where they refer to variables or geometric axes.
Some strings may say "typo", but be correct, however, they will have a
sister string where the typo occurs and notes have been made to make
it easier to identify.
The note "URL in caps" occurs where "url" has been incorrectly written
in lowercase, URL is an acronym for Uniform Resource Locator and
should be in caps.
The note "CamelCase" raises the question of whether it is necessary to
use CamelCase in this string. CamelCase is a geeky way of grouping
terms, but it is very difficult for localizers to understand whether
the concatenated string can be localized or not. It is better to
group words into single terms by using quotation marks rather than
using Camel Case.
see Bert's comment in this message about CamelCase
I have not forgotten my promise to calculate a new glossary file
specific to eToys. I got some excellent feedback on this issue from
Dupuy, but I would like to see fi some of these suggested i18n
improvements could be made as it would result in a better
poterminology glossary calulation.
Thank you for your attention to this matter.
More information about the etoys-dev