Date: Tue, 1 Jul 2014 22:19:05 +0200
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
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<[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.
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
