On Wed, Jul 2, 2014 at 6:06 AM, Jon Peli Oleaga <oleaga...@hotmail.com> wrote: > Thank you very much; to all of you who have shown me the way to change most > of the “html” files using CMS. I will try to do small corrections on them > that way. > > As for the download file, I do not understand very well some of the technical > issues to take into account to solve the problem, but I am sure the way you > chose is going to be a lot better than the one I would chose. > > Any way, I have some problems with the links (the “support” link on the > header leads to a page written in Basque but the same link on right menu > leads to a file written in English ) on the download “html” file > automatically generated > .
I see this as well. I don't see where this link comes from. Marcus, could you take a look at: http://www.openoffice.org/xx/download/index.html The "support" link in top nav goes to the localized xx/support/index.html But the link on the right is hard-coded to the default /support/index.html I don't see this URL in the list of customized ones in the message properties Javascript. Where is this URL defined? How do we customize it so it points to the same NL version as the topnav version does? Thanks! -Rob > Probably the reason for that is that presently the files translated into > Basque only are located on the “eu-test” directory and all the files on the > “eu” directory are files in English; and replicating the files on the > “eu-test” directory on the “eu” directory could solve the problem. But I am > not sure of that. > > Could we do that replication, even if the files on the “eu-test” directory > are not completely actualized? > > Jon > >> Date: Tue, 1 Jul 2014 22:19:05 +0200 >> From: marcus.m...@wtnet.de >> To: l10n@openoffice.apache.org >> CC: robw...@apache.org; marcus.m...@wtnet.de >> Subject: Re: National web sites (Basque) >> >> Am 07/01/2014 06:34 PM, schrieb Rob Weir: >> > On Tue, Jul 1, 2014 at 8:36 AM, Jon Peli Oleaga<oleaga...@hotmail.com> >> > wrote: >> >> >> >> >> >> >> >> I think that the present procedure to update the pages of the national >> >> web sites is using some auxiliary files (.mdtext, .js …) that are >> >> processed to give the final “.html” files to upload into the server. >> >> >> >> I am not sure of that, but I think too, that presently we can not correct >> >> directly those final files. >> >> >> > >> > Correct. You are talking about the new download page. The page that >> > the user sees in their browser is created, at run time, by Javascript. >> > So there are no "final file" that you can edit. You can only edit >> > the intermediate files, e.g., the HTML template /download/index.html >> > and the Javascript file with the strings, msg_prop_l10n_eu.js. >> >> This is indeed the intended way to centralize the handling of the >> download. It's important that the download is working without problems >> regardless of language, OS and version. >> >> In former times every language group has done it on their own. If there >> was a problem of short resources or the volunteers stopped their work, >> then the websites get stuck and the download was not updated or wasn't >> working any longer at all. >> >> Withe new new way to maintain the download experience we can avoid >> problem at least in this area. >> >> BTW: >> (Nearly) All other webpages are directly editable - via SVN or the >> Apache CMS. >> >> > I'd highly recommend limiting the editing to only the message >> > properties file. We're trying to avoid a divergence in the structure >> > and contents of the HTML file. We've found that if these files >> > diverge then we have a bad user experience when a new AOO version >> > comes out. The NL websites either break or are outdated. Having a >> > structured way of managing these complicated pages (like the downloads >> > page) makes it a lot easier to handle updates. >> > >> >> But the files automatically processed in that way sometimes are incorrect >> >> for languages with word order in the sentences not equal to the one used >> >> in English. >> >> >> >> For instance, in Basque there is no way to translate the item “ is >> >> unavailable for “ because English sentences like “XXX is unavailable for >> >> YYY” should be translated to something like “XXX is unavailable YYY-for” >> >> >> >> This is just an example, but similar things occur frequently. >> >> >> >> So, if we consider XXX, YYY and ZZZ constant values that must appear in >> >> any language, as long as the .html file generating process is not able to >> >> consider 3+1 (constant number +1) language dependent strings to combine >> >> with them in the following way: >> >> >> >> lang.dep.str.1& XXX& lang.dep.str.2& YYY& lang.dep,str3& ZZZ& >> >> lang.dep.str4 >> >> >> >> we can not assure that the automatically generated “.html” Is going to >> >> be correct for all languages. >> >> >> >> Actually, even with the (N+1) strings we can not assure the correctness, >> >> because the N constants do not necessarily appear in the same order in >> >> all the languages. >> >> >> > >> > These are standard problems that we encounter whenever we localize. >> > The developers don't always understand the subtleties of other >> > languages and make too many assumptions. This can happen in the AOO >> > code as well. But we avoid forking the code to fix it. >> > >> > In your example, it would be better to put the entire sentence, "%1 is >> > unavailable for %2” into the strings file. so the translator can >> > change the word ordering as needed. >> >> Right, seems to be the better way. >> >> >> I think that trying to implement an automatic procedure to get final >> >> “.html” files for any language nowadays is too complicated and that, >> >> because of that, it should be possible to make small changes directly on >> >> the final “.html” files. >> >> >> >> Not directly the translators, of course; but AOO should accept uploading >> >> directly the corrected final “.html” files sent by them. >> >> >> > >> > I think we need to avoid the mess of having each NL website change >> > Javascript. Small, changes to HTML is probably fine. But script >> > changes need to be centralized. >> > >> > Any ideas, Marcus? >> >> I agree. For the download we should avoid individual changes in every >> part of the final HTML files. Otherwise we get back to the old times. Sorry. >> >> We are still on the way to fix this old mess. And this is a lot of work. >> >> > I think we're almost to a good solution here. A more perfect >> > solution might be: >> > >> > 1) Add a version ID to the msg_prop_l10n_cc.js files or to the file >> > name. Version the page generation logic as well, so it picks the >> > right version of the properties file. The idea would be to allow >> > fixes like the kind Jon needs for Basque to be added to the script >> > without forcing an immediate re-translation for all NL pages. We >> > need some way of doing this in a staged fashion, without breaking >> > anything. >> > >> > 2) Maybe get that file into Pootle? That also makes it easier for >> > translators. >> > >> > >> > The goal is to make it easier to translate, but also have a structured >> > way of evolving the localization in general. >> > >> > Any other ideas? >> > >> > -Rob >> > >> > >> >> Is there, presently, a procedure to make small changes on the final >> >> “.html” files without having to change the auxiliary files and regenerate >> >> automatically those final “.html” files? >> >> >> >> What must we do simply to change a bad link in a final “.html” file? >> >> You can do changes on any files via SVN or Apache CMS if you have the >> commit permission. >> >> However, for the download area this should be done with big caution as >> every change could lead very fast to changing all localized download >> webpages. >> >> Marcus >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: l10n-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: l10n-h...@openoffice.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: l10n-unsubscr...@openoffice.apache.org For additional commands, e-mail: l10n-h...@openoffice.apache.org
