openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: Portuguese download broken
Date Wed, 11 Jun 2014 17:51:10 GMT
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message