Dear Pootle developers,<br><br>The Sugar Labs / OLPC / eToys localization community faces a somewhat unique challenge and I am hoping that you might be able to offer some insight or assistance.<br><br>It is a given that it is extremely useful to be able to track L10n progress and to use the &quot;untranslated&quot; or &quot;needs attention&quot; review links as a means of quickly focusing effort on areas where it is needed.  However there are a number of terms in our projects that for one reason or another may not translate well and some language projects prefer to leave them in their original form.  No feature exists to flag such an entry as &quot;do not translate&quot;.  While it is possible to simple select the &quot;Copy&quot; option (which would leave it flagged as &#39;unchanged&quot; on the review tabs), this would seem to have the unintended consequence of bloating the localization files beyond the minimalist change set needed. <br>
<br>This is a significant issue for OLPC in that builds are made with a select number of localizations included and the limited space available on the XO hardware causes the developers to make some difficult choices about whether to cut languages out of the builds to save space (even a handful of MB makes a difference when you are limited to 1 GB total storage on the XO).<br>
<br>My question is what is the best way to deal with these conflicting goals, keeping good stats on strings that have been &quot;human-reviewed&quot; versus those that are untouched and reducing the size of the localization change set needed.<br>
<br>One option that occurs to me would be to create a &quot;Do not translate&quot; status flag (similar in concept to &quot;fuzzy&quot;) that would count the string as human reviewed, but not unnecessarily contribute to the file size of the PO as a &quot;copy&quot; would.  I am open to other solutions for this conundrum, either technical or administrative, but there is a certain appeal to the technical solution as we have a highly distributed localization community (over 100 languages or dialects in progress) and establishing manual business rules for all to follow can be challenging in it&#39;s own right.<br>
<br><a href="http://translate.sugarlabs.org/">http://translate.sugarlabs.org/</a><br><br>A related issue has come up with our Spanish language localizations.  Certain terms are translated differently in different regions, this leads to well intentioned, but sometimes disruptive, reversions and changes in the lang-es project.  The Spanish-speaking Sugar community is reluctant to fork the lang-es project into multiple locales because of the administrative overhead of maintaining multiple localizations, but nonetheless would be interested in a minimalist changeset feature that would allow the core lang-es to be used except where a local variant (trivial example: frijoles versus habichuelas when referring to beans) should override.  This is not a small problem as there are hundreds of thousands of XO laptops deployed to children throughout Latin America.<br>
<br>Any suggestions you may have as how to address these issues would be most welcome.<br><br>cjl<br>volunteer Sugar Labs / OLPC / eToys Pootle admin<br><div style="visibility: hidden; left: -5000px; position: absolute; z-index: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" id="avg_ls_inline_popup">
</div>