Issue Details (XML | Word | Printable)

Key: SQ-950
Type: Task Task
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: Chris Leonard
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.

eToys i18n suggestions

Created: 17/Jun/11 09:33 AM   Updated: 17/Jun/11 09:33 AM
Component/s: translation
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. File All_eToys.ods (378 kB)

 Description  « Hide
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

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

Thank you for your attention to this matter.

There are no comments yet on this issue.