Sorry, when I have sent my previous mail the text has been unformatted, and part of it is difficult to read. I am sending again the message but this time better formatted. It is in between the lines with asterisks. > From: oleaga...@hotmail.com > To: l10n@openoffice.apache.org > Subject: RE: National web sites (Basque) > Date: Thu, 3 Jul 2014 01:57:51 +0000
> > Am 07/02/2014 04:33 PM, schrieb Rob Weir: > > > 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. > > > > right, it's hard-coded inside the HTML file. The link text and title > > text can be customized but not the link itself. Please have a look into > > the source code of the download webpage [1]. > > > > > Where is this URL defined? How do we customize it so it points to the > > > same NL version as the topnav version does? > > > > I need to add the links as variables to the "msg_prop_..." file also and > > re-work the "boxed_download.js" file to show them. > > > > Then you just need to delete the nearly hard-coded part to show the nav > > bar and insert the function call to create it: > > > > createNavigationBar(); > > > > On the test page [2] it's nearly done. Only the customized links are > > missing. Maybe something for the weekend and then I can put it into > > production. > > > > BTW: > > When re-working the whole stuff I thought it wouldn't be necessary to > > customize also the URL. Maybe a wrong decision. ;-( > > > > [1] http://www.openoffice.org/eu/softwarea/index.html > > [2] http://www.openoffice.org/download/test/index.html > > > > Marcus > > > > ********************2014-07-03In my previous mail Isaid: > If you want to keep in the localized “sites” the directory structure and file > names of the English “site”, perhaps it could be possible in the generated > html file instead of writing; > > + "<h3>" + l10n_nav_headline_3_text + "</h3>" > + "<ul>" > + "<li><a href='http://www.openoffice.org/support/index.html'" > + "title='" + l10n_nav_support_title + "'>" + l10n_nav_support_text + > "</a></li>" > + "<li><a href='http://openoffice.apache.org/native-lang.html'" > + "title='" + l10n_nav_local_title + "'>" + l10n_nav_local_text + > "</a></li>" > > to write > > +"<h3>" + l10n_nav_headline_3_text + "</h3>" > + "<ul>" > + "<li><a href='http://www.openoffice.org/"; + NL_LANG + > "/support/index.html'" > + "title='" + l10n_nav_support_title + "'>" + l10n_nav_support_text + > "</a></li>" > + "<li><a href='http://openoffice.apache.org/"; + NL_LANG + > "/native-lang.html'" > + "title='" + l10n_nav_local_title + "'>" + l10n_nav_local_text + > "</a></li>" > > and so on > But if we want to keep the directory structure and file names of the English > site, perhaps it would be a better way (slighly less prone to errors) to > define somewhere at the begining of the javascript a new variable in this way > NL_DIRECTORY="http://www.openoffice.org/+NL_LANG+"/"; ;if (NL_LANG = "en") > NL_DIRECTORY= "http://www.openoffice.org/ "; or the correct way of doing that in javascript, and then write +"<h3>" + l10n_nav_headline_3_text + "</h3>" + "<ul>" + "<li><a href='" + NL_DIRECTORY + "support/index.html'" + "title='" + l10n_nav_support_title + "'>" + l10n_nav_support_text + "</a></li>" + "<li><a href='" + NL_DIRECTORY + "native-lang.html'" + "title='" + l10n_nav_local_title + "'>" + l10n_nav_local_text + "</a></li>" Regards, Jon > ********************2014-07-03 > > > > >> 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 > > >>> > > >> > > > > > > > > -- > > > > Ciao > > > > Marcus > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: l10n-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: l10n-h...@openoffice.apache.org > > >
