On Tue, 21 Jan 2003 00:48:02 +0000 (GMT) Andrew Dunbar <[EMAIL PROTECTED]> wrote:
...
AD> One thing struck me when I was looking at it recently.
AD> Now that it nicely supports multiple languages, I'm
AD> wondering why en-US spelling is semi-hardcoded. It
AD> always struck me that the only real reason we shipped
AD> with en-US only and made the others optional was
AD> because it was too much work to make and maintain
AD> other
That is a good question. I thought we only shipped
with en-US because we didn't want to provide a dozen
builds, the only difference being the dictionary included
with the installer; with including them all producing a
setup file too big for downloading (given most people
will only use 1 or 2 dictionaries -- but different from
other people). As far as maintaining goes, yes I took
great pains so to add a dictionary only requires the
insertion of a 1 line macro and should be easy enough
to update if new ones are available (or existing ones removed).
AD> versions. Now it looks like you've actually done this
AD> work I think it would be a good idea for the installer
AD> to automatically tick only the user's language and
AD> treat English (US and British) just like any other
AD> language. Or maybe I'm missing something (:
AD>
Well there are two different issues here.
Please let me know what is desired.
(When I refer to build time with NSIS, I mean when the *.nsi file
is ran through the nsis compiler to generate the resulting
setup program. Also defines refer to ones set in the AbiWord2.nsi
file or passed as command line defines, not ones set anywhere
in AbiWord [though they could be passed through the make system])
Note:
- option 1ai is basically what we have now, except I will change the
hard coded en-us dictionary to a build-time option of which to include.
- option 1bii is the one I'd like to use. No dictionary is actually
included with the installer, but for those with a network connection,
it is easy enough to install whichever dictionaries are wanted during
the install. Those without a network connection simply have to download
a second (or more) file corresponding to the dictionaries they actually
want installed (i.e. manually do what the installer can do if you
have a network connection).
1) do we even want to include a dictionary with the installer?
a) yes, well how many and which ones?
i) just one, we might as well stick with just English, otherwise
we still have the issue of providing multiple installers;
though it would be easy enough so the actual one chosen
is a build time define (if we continue to include just one, I
will try to ensure this is easy enough to do, and move the
English(US) into the same set as all the others -- i.e.
make it only special in the sense its the default one included)
ii) several, which ones? why those?
iii) all, this is supported, (though English(US) will be removed
from its own section and put with the rest).
To do simply ensure NODOWNLOADS & OPT_DICTIONARIES both defined.
b) no, but should they be downloadable?
i) not included and not downloadable simply requires not
defining OPT_DICTIONARIES; (and modifying English(US) so
specified the same as other dictionaries (via the macro
and not with its own special section)).
ii) simply not define NODOWNLOADS and define OPT_DICTIONARIES and
all available ones (added via 1 line macro) are now choices
for downloading. If at least one is selected, the user is
even prompted to select a mirror (with the option of typing
in a customized base URL).
c) leave it as it is, that is, english(US) dictionary is special,
it is always included and in a section all its own.
2) language selection
if we include all dictionaries (either all downloadable or all
actually present in the installer) then I will adjust it so
a matching dictionary will be selected. The catch here, and I'm
still waiting on a reply for Jordi regarding a similar issue
(the language AbiWord starts up in), is that the installer's
knowledge of languages does not exactly match with AbiWord's
knowledge of languages -- the installer uses Windows LCID's
[I think anyway, e.g. English to the installer is 1033] and
has no notion of locale (i.e. US vs GB for en-US vs en-GB).
In this case there has to be logic to determine which locale
one to select (or do we just the select the 1st/last/all for
a given language?) Then there is the issue like en-NZ that uses
the same dictionary as en-GB, so its not included in the list
(easy enough to add, but unless you are only downloading them
you will get unnecessary duplicates in the giant installer
[should anyone ever want to make one -- such as for a CD])
but after I get the installer to preset abiword to startup
in the same language selected for installation (after all
why should abiword startup in Spanish if I told it during
install to use English, e.g. if Windows is presently set
to a spanish region) then the dictionary auto-ticked
should match this choice (lang-locale).
Anyway,automatically selecting the appropriate dictinary isn't
hard to do, just requires making some decisions as how to make
the decision of which is selected. For now I'm thinking of
modifying the dictionary addition macro so it includes an
option that indicates the default for a given language (e.g.
autoselect 'en-GB English' whenever English is the selected language).
AD> Andrew Dunbar.
AD>
Let me know what you guys think or if I need to clarify anything.
Thank,
Jeremy
