[Sugar-devel] Moon string translation difficulties
garycmartin at googlemail.com
Mon Jun 20 11:15:57 EDT 2011
On 20 Jun 2011, at 14:51, Chris Leonard <cjlhomeaddress at gmail.com> wrote:
> On Mon, Jun 20, 2011 at 9:05 AM, Gary Martin <garycmartin at googlemail.com> wrote:
>> Hi Chris,
>> I just wanted to ping and ask your opinion on how best to help translators know what to do when they encounter variable string formatting of some kind. For example, while trying to manually fix up strings with missing /n line ends in ps.po (to get a release out today), I've also just noticed that all the translated strings fail to include the value data and formatting. This renders the information panel useless as it will contain no actual luna information other than static text, it might even cause the activity to crash on launch.
>> Do we need to fill the source with #TRANS: comments describing string formatters?
>> I usually run my activity tests in English, Spanish, sometimes French, and maybe one other for curiosity, just to make sure translation locale files are working in a bundle release. Testing more than that becomes rather time prohibitive. Are there any other tools you are aware of that could be used check the validity of strings so we can focus testing on the problem cases?
> Unfortunately, I know the Pashto strings to be in poor condition. I
> have reached out to OLPC Afghanistan and have been told (again) that
> they will be working on them. Mike Dawson is a good guy, but the
> localizers don't follow through very quickly and given the difficulty
> of their circumstances (they are in Afghanistan after all), I am
> reluctant to be harsh with them about quality issues, although I did
> let them know that the poor quality pf lang-ps was causing builds to
Many thanks for the information. FWIW I have manually tidied the po files to get a build out today:
Having tested it in Pashto on an XO1 11.2.0 build 22 I can confirm Moon will fail to start due to missing variable substitutions in the current ps.po strings. I also noticed the unknown Unicode block glyph appearing in many of the strings that do have translations (in Moon, and else where in the Sugar UI).
> More proposed solution is this:
> I will review the Pashto Honey activities, looking especially for
> printf errors (variable substitutions) as they may cause particular
> problems for builds and as you mention, result in poor UI outout.
> pofilter checks described here:
Fab, will try and take a look once I have the release out.
> This review is easily done by using hte Review tab in Pootle which
> flags all pofilter errors for attention and provides quick links to
> the flagged strings.
> In rare cases, I may be able to fix them (e.g. where the %s or %d is
> at the end fo the strings), although my preference woudl be for a
> native Pashto speaker to make sure this does not mangle the languages
> syntax as I'm not sure of subject-object structure in Pashto.
Yes I did consider trying to put them back in myself, so that it at least launches on machines set for ps, but need to get this build today and wasn't sure how many other languages may need the same (will look at the above test URL later, should be a big help).
> If I cannot see an easy fix, I will flag the string as "fuzzy" and
> recommit the Po file. This sill server two purposes. 1) strings
> marked fuzzy are ignored in the build process and shouldn't result in
> erros, 2) the fuzzy string is not counted as complete in Poolte and is
> flagged for attention by the localizer. This does not discard the
> work on the string as the words m,ay be right, missing only the
> placement of the variable.
> Does that sound like a reasonable approach?
> It will result in some strings coming out in English (instead of
> mangled Pashto), but I think that is the best solution until a native
> Pashtun can properly localize the strings.
Yes sounds good to me, that at least gets us an activity that will launch.
> I'll ping you a note when my review of Pashto is complete and I have
> recommitted Moon.
More information about the Sugar-devel