Am 06/09/2014 11:31 PM, schrieb Kay Schenk:
On 06/09/2014 02:21 PM, Marcus (OOo) wrote:
Am 06/09/2014 11:10 PM, schrieb Kay Schenk:
On 06/09/2014 01:45 PM, Marcus (OOo) wrote:
Am 06/08/2014 12:45 PM, schrieb Andrea Pescetti:
Bruno Coelho wrote:
Just check another thing, i search oppenoffice in google the first
result
take me to https://www.openoffice.org/pt/ then i click on "transferir"
that
mean Download in Portuguese but i cant see a button to download
It's the same for
https://www.openoffice.org/it/download/
http://www.openoffice.org/es/descargar/
and possibly others.
What's gone wrong? Some old JavaScript issues that resurfaced with the
new download page? Breaking download pages is always bad, hopefully the
new system will fix this.
I've documented the problem in this issue:
https://issues.apache.org/ooo/show_bug.cgi?id=125070
It would take a bit longer to get the old functionality back working
because it was completly reworked.
Unfortunately, I have a tooth problem and need to visit the dentist
tomorrow. So, I'm not able to do any larger things and this would be
one.
Marcus
I think we've got work arounds in for our binary release now (I will
double check again.). I would not be in favor of reverting BACK to the
old download because I think what you've done is superior despite some
hiccups. esp the localization aspects.
ups, I don't meant a complete revert but just to get the old
functionality back (the old functions within "download.js"). Of course
the current look& feel would stay but to have the old working - kind of
- in parallel.
If I would have known that we have in the meantime so many download
pages that rely on the main webpage and its functions, I would have made
old and new working in parallel. ;-(
I could think of the download.js and release matrix JS file. But I'm not
sure if this is all or if something additionally has to be changed.
It seems we are in a lucky position:
It's easier than thought as only the following has to be done:
- Add the following 4 files back to the main download area:
- download.js
- globalvars.js
- exceptions.css
- release_matrix.js
- Rename the new files with adding something (e.g., "download2.js") to
separate from the old files.
- Change the file references in the "head" part of the "index.html" in
the main download webpage, so that the new files will be used.
- Delete the added "Click this temporary link to download"
text box in every localized "index.html" file.
That's it.
I've tested this locally with the "es" download and it works.
Now the golden question: :-)
Do we want to go on with the temporary way?
Or change back to the old One-Click-Download behavior?
As it was my work that broke the localized webpages of course I would
volunteer to do the work.
So, some of the native lang DLs will just go to Engligh main for now.
I wish just looking at the logic, and seeing what we could do to at
least provide the native language automatically IN the English DL at
least. I'm sure there's a relatively easy way to that. This is actually
making me braver to just use Google translate to setup the download
sub-directories for our released binary areas, but I can't do much on
this until next week.
I've made a "proof-of-concept" with the German download webpage. It's
with the new select boxes and fully localized. Maybe we can adapt this
to the other langauges.
Yes, I saw this and that's when I started digging a bit more.
We may need to further discuss how to handle non-JS folks and if we need
to reinstate other.html as a static page.
When you now disable JavaScript and reload the main download webpage
then the text and links within the "noscript" HTML tag are displayed.
Now the ASF closer.cgi script [2] is used which is not optimal for our
end users as there are too many possible ways and too many clicks. But
here we can think of using the Sourceforge.net entry page [1] and
improve the display of file names as they are currently shown cut off.
From my Web Software Engineering experience (my daily job) I know that
the averge user is not browsing with disabled JavaScript (offtopic: or
without cookies) as the very most majority of websites use it nowadays
to offer their full user experience.
Furthermore, I don't like the idea of a static webpage of this size. It
will become bigger with every new released language. I've done the
current improvements to avoid this piece of effort. ;-)
[1]
http://sourceforge.net/projects/openofficeorg.mirror/files/4.1.0/binaries/
[2] http://www.apache.org/dyn/aoo-closer.cgi/openoffice/
My 2 ct
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
