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 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. The same approach as suggested by Andrea could be used for the blue boxes. 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. Thoughts? > > 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 > -- ------------------------------------------------------------------------- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
