Am 06/11/2014 01:23 AM, schrieb Andrea Pescetti:
Marcus (OOo) wrote:
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.
This will cause some caching issues (for those who have already used the
new download page) but indeed it seems not so bad.
caching issues shouldn't be a problem. Just reload the browser window.
Furthermore, the website will browsed again and again in case of new
download wishes.
- 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.
OK, unless you wish to rename the old ones (to download_old.js and such)
if this is still easy, since we may want to actually get rid of the old
mechanism in favor of the new one.
It is more effort the other way around as I would need to change every
localized download webpage. Of course this is also a possible way. We
just need to agree what we want.
- Delete the added "Click this temporary link to download"
text box in every localized "index.html" file.
For my commits, this means reverting
http://svn.apache.org/viewvc?view=revision&revision=1601211
http://svn.apache.org/viewvc?view=revision&revision=1601213
Of course, feel free to revert both when replacing them with a better
solution.
Now the golden question: :-)
Do we want to go on with the temporary way?
Or change back to the old One-Click-Download behavior?
Could we go back to the old behavior (whatever the file names) but then
try and encapsulate all logic differently?
OK but ...
The most difficult part is that one just wants to localize the page, but
still there's a lot of JavaScript around. From a maintenance point of
... this is a totally different topic. ;-)
view, I would prefer to have a "createDownloadDiv(var strings)" function
that takes an array of all strings needed to build the localized div and
returns the div markup. This would simplify a translator's work, since
they would only have to translate a long but understandable function
call. If this is unclear I can make an example. And this would also
guarantee that we can adjust it more easily.
Yes, I thought about this already a few months ago. A first result was this:
http://ooo-site.staging.apache.org/download/test/l10n/index_en.html
I've done now an example with the new select boxes. You can look into
the HTML code of the main or German download webpage. You will find a
file "msg_prop_l10n_en.js" resp. "msg_prop_l10n_de.js" with all strings
that could be localized. These are assigned in the JS code parts of the
HTML file.
That means there shouldn't be a need to dive into the HTML+JS code
sections to find the things to translate. OK, except for the "noscript"
parts as I don't know a better way for the moment. So, if someone knows
a way please tell me.
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. ;-)
If we really want to have a webpage to serve all needs of people who
disable technologies, we could build other.html with a script that scans
the files tree and simply outputs a minimal table. But I don't know if
this is worth the effort.
The users that wanted to have a different install file than offered by
the previous One-Click-Download was surely higher than now with the new
"select-what-you-want" way. Only these users were the target audience
for the "other.html" webpage. To build up a relatively easy way to get
what they want. But the noscript users were not the audience.
The number of users are not very high. It's simply no fun to browse
nowadays through the Internet with disabled JavaScript. Maybe it's even
less funny compared with disabled cookies. ;-)
Furthermore, there are some add-ons like "Noscript" where you can
fine-tune which website is allowed to browse with enabled JavaScript and
which not.
Right, the "other.html" could be scripted somehow. But at the moment I'm
still convinced that it is not worth the effort.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
