Right now the way it works is that if any language other than en_US is
requested, then all translations are downloaded, because they are all in the
same package. This is the 200K I was referring to. The only solution to that
is to have the different translations in different packages and different
Jar files. (pt and pt_BR could be in the same package, though.)

In the interest of getting 1.6 out the door, I'd like to propose that we
strike the en_GB translation for now and instead make that part of 1.7,
because implementing it requires changes to GT.

Then Nico or I can work on streamlining the applet loading for 1.7.

Or, if people want, let's get this straightened out now and hold off on
releasing 1.6 until that streamlining is done.

Bob


On Mon, Oct 6, 2008 at 5:08 AM, Angel Herraez <[EMAIL PROTECTED]> wrote:

> Yes, I see the increased size of the applet as an important issue.
>  I had already thought of that before, but was sure we have to
> sacrifice for the usefulneess of localizations.
>
>
> > also -- this introduces a need for translations of "English - United
> > Kingdom" in every translation. Is the plan to have these done prior
> > to 11.6? [I thought we were done with translations...]
>
> Now that this pops-up, I must say that I am not comfortable withe the
> way the "language" menu entry is managed --I understand that there
> may be technical reasons for it--.
> For example: a Spanish-speaking user visits a Dutch lab and will see
> Jmol menu in Dutch. What is "Spanish" in Dutch? No idea.
>  I don't see the point of having a language menu that says "Taal >
> Spaans". The first part is unavoidable, but it would be better that
> the second says "EspaƱol". (And maybe the first one should be left in
> English.)
> That is, in my opinion the language names shouldn't be translated.
> The usefulness is not in advertising how many languages we have, but
> in letting the non-polyglot user find his language easily.
>
> As I said, this many be technically cumbersome. But it's my
> preference, and would avoid us translating all new language names --
> which for some countries is even difficult--
>
>
> >     3. Should we perhaps package the languages classes separately or in
> >     separate groups so that the entire translation package isn't
> >     downloaded with any particular language switch?
>
> If that's technically possible, it woul be good to accelerate
> download of pages. However, we may get into trouble. I guess that the
> nonloaded classes would be downloaded if the user tries to switch
> language from the popup menu, right? That would be OK.
>
> Several reflections:
> * a reduced download is great
> * although it's very nice to have the applet in one's language --and
> automatically so--, if a page has its (long) content in English,
> havign the applet in English too is not unreasonable --and there's
> always the pop-up to change it. In fact, in some of my Spanish pages
> I've opted for forcing the switch of applet into Spanish by a script
> in the page.
> * being so, if the applet could be downloaded in English only, what
> would happen when Java requests the OS language? Would it be
> downloaded right away? I'm thinking of my Spanish users; we won't be
> using French, or Dutch, etc. normally; we can do with just English US
> and Spanish and a smaller applet.
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jmol-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>



-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers

Reply via email to