On Tue, Jul 1, 2014 at 8:36 AM, Jon Peli Oleaga <[email protected]> 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. 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. > 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 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? > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
