Qingjiang (Brian) Yuan wrote:
> Hi, Dave,
> Thanks for the reply, please see below for more information:
> 
> Dave Miner wrote:
> 
>>> The following are some options of the localization packages 
>>> installation:
>>>
>>> 1. Current solution, only C locale will be installed unless you 
>>> choose one of the big rules language as the installation language or 
>>> manually check GEOs from customized install.
>>> 2. Install all locales by default, inform customers to deselect some 
>>> only if the disk space is limited
>>> 3. Separate locale enabling packages from pure translation packages 
>>> and install all locale enabling packages by default, and install 
>>> other translation packages by manually selection during installation, 
>>> but this should be clearly explained to customers before they choose 
>>> "Default Install" or "Customize Install".
>>> 4. Provide downloadable, easily installable and removable locale 
>>> patches or packages so that customers can add/remove locales easily.
>>>
>>> Most Linux distros are using the 2nd option, but I prefer the  3rd 
>>> and also the 4th :-)
>>>
>> Clearly there's dissatisfaction with the current solution, so we'll 
>> just rule out #1 right off the bat :-).
>>
>> #2 is attractive, in that it's similar to the proposed answer to the 
>> driver problem - you may not know you need it until much later, and 
>> then having to hunt around for the right one is a painful experience, 
>> so let's just not make you do it.  I'd guess it's the simplest in some 
>> ways.
> 
> Right, it's the simplest way :-).
> Oops, I should change the #2 to the following since all of the locales 
> will also be installed in #3 by default:
> 2. Install all localization packages by default, inform customers to 
> deselect some only if the disk space is limited
> 
> One  problem is you will get translated GUI, error messages and online 
> help if you login to some locales to do some i18n testing. This is not 
> what most of the English speaking developers would like to see if they 
> are only doing some i18n testing for their software products.

That would seemingly only be an issue if you actually set a non-standard 
locale as the default, though; you can login under your normal locale 
and just set it to an alternate locale for the processes where you're 
doing the testing.

> Another problem is unless the installed Solaris is something like a 
> SunRay server for many users speaking different languages from a 
> multinational company, usually it's not necessary to install the 
> translations of all languages :-)
> 

Yeah, it seems that the situations where you need all of them are pretty 
limited, so it may not be the best default.

>> I'm not sure what the engineering implications for #3 or #4 are (how 
>> much restructuring of existing packages, etc.), 
> 
> The package separation for #3 has already been done in Solaris. Basic 
> locale enabling packages (locale enabling, minimum fonts, input methods, 
> iconv, X11) are in Solaris Software CD 1 for CD based installation 
> purpose, a few are in CD 2,  most of the other localization packages ( 
> extra fonts, input methods and pure translations, etc.) are in the 
> Languages CD. (Document translations are in separate docs CDs)
> 
> We are planning on the downloadable locales for #4, but not a lot 
> progress so far. We need to work together with installation team and 
> also CNS team to decide the format and how to release those downloadable 
> packages.
> 

This does have some commonality with locating and installing additional 
drivers, so we may be able to leverage any work that's going to be done 
for that realm.  One problem I see is that, while Update Connection 
might be attractive as a Sun solution, it's not necessarily oriented at 
being usable for other OpenSolaris distributions.

>> if you can elaborate on that it would be helpful.  I also don't have 
>> the stats for the amount of disk space that #2 consumes vs. what might 
>> be saved by the other alternatives; if you have some rough guesses, 
>> that would be useful data, too.
> 
> The current size of all localization files are about 900MB after 
> installation,  the translation packages are about 30MB for each of the 9 
> big rules languages, so it's about 900MB extra disk space for #2 and 
> 630MB (900MB - 9*30MB) for #3 where only locale enabling packages are 
> installed by default. And I believe more and more locales and 
> translations will be added into OpenSolaris very soon :-)
> 

So #3 is about a 15% premium for space, where #2 is about 20% vs. a 
current Nevada complete installation, I think.  Big enough numbers that 
we need to think a bit carefully about it, because it does affect both 
performance (as you noted subsequently) and ability to install just 
based on available space.

Dave

Reply via email to