Hi,
Christian Lohmaier wrote:
Hi *,
On Mon, Mar 20, 2006 at 12:15:24AM +0100, :murb: [maarten brouwers] wrote:
[offer multiple versions]
The german language project has it already working because
it's relatively easy to manage for just one language.
Another reason to offer older versions as well is because not all
Platforms have passed QA and stuff, so people can grab the RC (or the
last "approved" one) nevertheless.
Good point. I imho the end-user download page should to only support
QA'd stuff. We could just tell the end-user they are downloading the
latest stable version in their language (I wouldn't mind putting some
version indication behind the language for informational purposes).
The problem now, when we try to address offering different versions, is
that incorporating direct downloads (which I guess is the ultimate goal)
from this download page becomes an even greater problem, especially
since naming and releases are so irregular.
Well, the old names (the relative part of the URL )don't change. Thus
why I think having complete relative URLs is better than trying to
assembe URLs.
Well, that was kind of what I was referring to. I would however really
like to know how you think version/language/server/os can all be
_independent_ variables, since the german script currently is simpler in
the sense that it only supports 3 of them, and the solutions, correct me
if I'm wrong, you brought up so far were only a kind of work-around,
matching language to version, or language to os. Therefore my suggestion
was to drop the version variable.
[...]
My goals (prioritized):
1. Servers should be randomized, making better descriptions is allright,
but as it's such an easy thing to accomplish using javascript, and code
is already available...
that is currently one line of js-code in the german script.
document.download.mirror.selectedIndex = Math.floor (
Math.random()* (document.download.mirror.options.length - 1) );
:-)
2. One should be able to download OOo in their native language directly
(as that is assumed by the interface as we have it now). Different
option is to remove the language dropdown completely, and just refer in
text to the international pages, else it doesn't make sense
I agree.
It seems that Kay doesn't think other native languages should be
incorporated. That would make the solution to the problem very simple:
Just start using the de-projects script, and separate the whole language
selection. I would then be very interested in offering the script in a
global repository, so that it can be used by all native language
projects (who still need to maintain the arrays). I am sorry Kay, but I
don't see why put any effort in actually rewriting what the german team
has already accomplished.
3. With or without JRE should actually be a checkbox (it's a minor
issue, but makes more sense)
good idea.
Well, let's put this minor issue on the todo list :)
[...]
Future goals:
- Incorporate P2P downloads: Can be another checkbox, followed by a
dropdown showing the three supported P2P methods.
I think this is not a good idea. People not knowing P2P but still
selecting that option will download a small torrent file or will be
prompted with a link that their browser cannot understand.
Then they will report errors like "I cannot launch the installer" or
similar.
Valid point. Guess we should keep calling it future goals ;)
- Offering ISO's (in advanced downloads)
how would you choose between "normal" and "advanced" download?
The normal download page should only show the option: operating system
and language and version (well, we've yet to decide between language or
versions or both). All other variables should be hidden by default imho
(including the text-field showing the complete url and the manual server
selection). A simple javascript+css show/hide operation, just as I used
for the download now, could then toggle the display of advanced options.
- Creating an python script (or whatever), that will make maintenance of
these pages much more easier
That's a task for when we know what information we need to build the
download-page. But I don't think maintainance is a big problem anyway
(depends on the layout of the js of course)
True. Yet when also static pages need to be maintained, we maybe could
generate both static and js-powered download pages in one run. But let's
forget about this point for now.
g.,
Maarten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
