openoffice-l10n mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <>
Subject Re: National web sites (Basque)
Date Tue, 01 Jul 2014 20:19:05 GMT
Am 07/01/2014 06:34 PM, schrieb Rob Weir:
> On Tue, Jul 1, 2014 at 8:36 AM, Jon Peli Oleaga<>  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.

(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”
>> 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 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message