[etoys-notify] [JIRA] Created: (SQ-950) eToys i18n suggestions

[Chris Leonard (JIRA)]

eToys i18n suggestions
----------------------

                 Key: SQ-950
                 URL: http://tracker.squeakland.org/browse/SQ-950
             Project: squeakland
          Issue Type: Task
          Components: translation
            Reporter: Chris Leonard
         Attachments: All_eToys.ods

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 beleve that they all deserve
careful consideration.

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
Terminology project.

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
with.

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
http://lists.squeakland.org/pipermail/etoys-dev/2011-June/006272.html

Thank you for your attention to this matter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.squeakland.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira