openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <>
Subject Re: Portuguese download broken
Date Thu, 19 Jun 2014 19:05:39 GMT
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
>>> 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
> 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:

> 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 

> 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 

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. :-)


>> Yes, I thought about this already a few months ago. A first result was
>> this:
>> 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:
For additional commands, e-mail:

View raw message