Am 06/19/2014 12:27 AM, schrieb Kay Schenk:
On 06/11/2014 10:51 AM, Marcus (OOo) wrote:
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.
After spending a while looking at approach more in depth, I agree with
Andrea here in terms of trying to set this up as simpler js calls
somehow. Conceptually, what's there now (in
http://www.openoffice.org/download/test/) provides the utmost in
flexibility, but it comes at the cost of complexity. And, since we have
roughly 35 native language download areas that need attention, I think
we need to look to simplicity to expedite the situation.
I've looked again to Andrea's idea to outsource the JS creation of the
green box into a separate file and think now it's great with regard to
other NL webpages. Then only one file needs to be changed and it will
work for all - for all that have included the JS function call.
So, this is already implemented even when I've not stated separatelly.
;-) Please check:
http://www.openoffice.org/download/index.html
http://www.openoffice.org/download/boxed_download.js
I think the "tips" strings could match the actual parameter strings,
thus eliminating some redundancy there. I'm not sure we need "tips" for
the selection box items of OS etc, so maybe more eliminations here.
Of course they are not the most important part. However, I don't think
it would reduce any complexity. Furthermore, it has an advantage for
disabled people and it's best pratice to describe what the user could
expect.
The same approach as suggested by Andrea could be used for the blue boxes.
Sure, even this could be outsourced into the separate file. However,
here I don't see the use case for it. The purpose is very limited and
the links are relatively set in stone. It's very unlikely that they will
change.
But of course maybe you (or anybody else) can tell me better. :-)
And, I think the right side of the page -- the additional items should
be just be left intact as a block and let volunteers translate/change
this as they see fit rather than construct it with javascript.
This increases the complexity for the translators. For the colored boxes
they have to translate just a JS file that contains all strings. But for
the nav bar it's needed to translate the content directly in the HTML
file? Hm.
Thoughts?
I don't want to sound too negative. Much is possible but first we need a
clear strategy. So let's discuss. :-)
Marcus
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
