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 Sat, 05 Jul 2014 20:47:27 GMT
Am 07/02/2014 08:57 PM, schrieb Marcus (OOo):
> Am 07/02/2014 04:33 PM, schrieb Rob Weir:
>> On Wed, Jul 2, 2014 at 6:06 AM, Jon Peli Oleaga<>
>> 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:
>> 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]
> [2]

I've finished the work.

Now the complete "index.html" can be scripted via the included 
"boxed_download.js" file. Every kind of string or link is customizable. 
The "msg_prop_..." files are updated.

The error text in the sub-green box (OK, then sub-red) can now be 
customized if the translation is not possible. Please have a look for 
the following variables:


They have to be used respectivly like the variables:


Keep them empty to show the default error text.

The files in "xx" were updated, too.



>>> 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:
>>>> To:
>>>> CC:;
>>>> 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<> 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
>>>>>> 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 “
>>>>>> 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&
>>>>>> 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
>>>>> 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”
>>>> 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:
For additional commands, e-mail:

View raw message