On Thu, Jun 19, 2014 at 12:05 PM, Marcus (OOo) <[email protected]> wrote:
> 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 >From a total overall perspective, the new changes are certainly right on. Maybe I wasn't prepared for a larger overall strategy like this so soon, thinking that just initially, we were just addressing the incorrect download problems. So, time for more l processing by me on all this. And, initiating changes for our existing native language web areas based on this new design. So, onward! > > > > 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: [email protected] > For additional commands, e-mail: [email protected] > > -- ------------------------------------------------------------------------------------------------- MzK "What you can do, or dream you can do, begin it; Boldness has genius, power and magic in it." -- attributed to Johann Wolfgang von Goethe
