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
.
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: [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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
