On Mon, Mar 21, 2011 at 1:17 PM, Martin Langhoff <span dir="ltr"><<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Sun, Mar 20, 2011 at 10:46 PM, Chris Leonard<br>
<<a href="mailto:cjlhomeaddress@gmail.com">cjlhomeaddress@gmail.com</a>> wrote:<br>
> As current XO builds come with a boot into GNOME UI option, we should be<br>
> considering the localization process of those UI elements as well.<br>
<br>
</div>Hi Chris,<br>
<br>
I am in agreement with your assessment of the situation -- that we<br>
need to ensure the gnome bits have their l10n bits.<br>
<br>
However... what I see is that we use the upstream i18n and l10n infra<br>
and output. In other words, Fedora and their upstreams. Our OS Builder<br>
seems to do a good job in including the right l10n bits.<br>
<br>
Are there specific things in the gnome world that you can report are<br>
not localized?<br>
<br></blockquote><div><br>My assessment, like yours, is that we are and should use the upstream
infrastructure and therefore should point our L10n community at the
right place to do that work. I would go further and say we should be
showing some love to the upstream by sharing our L10n community's time
and talents by letting them know which upstream strings flow down into
OLPC published builds and encouraging them to work upstream on the L10n
of those strings.<br><br>However, <br><br>1) I believe there are many more strings in the upstream than we are
using, so it would be good to have a specific listing of the packages
that we use to focus our L10n efforts on the most important strings.<br><br>As an example, Gnome 2.3.0 (stable) has about 45,000 strings and I'm guessing that only a fraction are relevant to an XO build.<br><br><a href="http://l10n.gnome.org/releases/gnome-2-32/">http://l10n.gnome.org/releases/gnome-2-32/</a><br>
<br>2) There are languages hosted in our Pootle server (specifically some of
the native languages from less developed regions) that are not
represented at all in the upstream, an effort should be made to have
those language projects created in the upstream and to point our unique
set of localizers there to do that L10n work (again focused on the most
relevant strings).<br><br>My specific proposal is to start by identifying the packages we pull (thus the request for help from one of our developers) and to build a listing on the wiki with links to the primary L10n hosting. When that documentation is done, I propose to advertise it on the L10n list and encourage efforts on the upstream strings. At the same time I would like to engage the upstream L10n community and possibly recruit them to working on our Pootle instance (not exactly a quid pro quo, more of a mutual assistance relationship).<br>
<br> Itoo beleive our build infrastructure is doing a good job of grabbing the upstream bits (where they exist), so I can't be really specific about a given string that may or may not be localized in a given language, I'm not reporting a specific "bug", just suggesting a documentation project to drive two-way traffic.<br>
<br>Does that make sense?<br><br>cjl<br><br><br><br></div></div><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>