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
