You are viewing a plain text version of this content. The canonical link for it is here.
Posted to l10n@openoffice.apache.org by Jon Peli Oleaga <ol...@hotmail.com> on 2014/07/01 14:36:03 UTC
National web sites (Basque)
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.
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.
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.
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?
RE: National web sites (Basque)
Posted by Jon Peli Oleaga <ol...@hotmail.com>.
Sorry, when I have sent my previous mail the text has been unformatted, and part of it is difficult to read.
I am sending again the message but this time better formatted.
It is in between the lines with asterisks.
> From: oleaga_jp@hotmail.com
> To: l10n@openoffice.apache.org
> Subject: RE: National web sites (Basque)
> Date: Thu, 3 Jul 2014 01:57:51 +0000
> > Am 07/02/2014 04:33 PM, schrieb Rob Weir:
> > > On Wed, Jul 2, 2014 at 6:06 AM, Jon Peli Oleaga<ol...@hotmail.com> 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:
> > >
> > > http://www.openoffice.org/xx/download/index.html
> > >
> > > 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] http://www.openoffice.org/eu/softwarea/index.html
> > [2] http://www.openoffice.org/download/test/index.html
> >
> > Marcus
> >
>
> ********************2014-07-03In my previous mail Isaid:
> If you want to keep in the localized “sites” the directory structure and file names of the English “site”, perhaps it could be possible in the generated html file instead of writing;
>
> + "<h3>" + l10n_nav_headline_3_text + "</h3>"
> + "<ul>"
> + "<li><a href='http://www.openoffice.org/support/index.html'"
> + "title='" + l10n_nav_support_title + "'>" + l10n_nav_support_text + "</a></li>"
> + "<li><a href='http://openoffice.apache.org/native-lang.html'"
> + "title='" + l10n_nav_local_title + "'>" + l10n_nav_local_text + "</a></li>"
>
> to write
>
> +"<h3>" + l10n_nav_headline_3_text + "</h3>"
> + "<ul>"
> + "<li><a href='http://www.openoffice.org/" + NL_LANG + "/support/index.html'"
> + "title='" + l10n_nav_support_title + "'>" + l10n_nav_support_text + "</a></li>"
> + "<li><a href='http://openoffice.apache.org/" + NL_LANG + "/native-lang.html'"
> + "title='" + l10n_nav_local_title + "'>" + l10n_nav_local_text + "</a></li>"
>
> and so on
> But if we want to keep the directory structure and file names of the English site, perhaps it would be a better way (slighly less prone to errors) to define somewhere at the begining of the javascript a new variable in this way NL_DIRECTORY="http://www.openoffice.org/+NL_LANG+"/" ;if (NL_LANG = "en") NL_DIRECTORY= "http://www.openoffice.org/ ";
or the correct way of doing that in javascript, and then write
+"<h3>" + l10n_nav_headline_3_text + "</h3>"
+ "<ul>" + "<li><a href='" + NL_DIRECTORY + "support/index.html'"
+ "title='" + l10n_nav_support_title + "'>" + l10n_nav_support_text + "</a></li>"
+ "<li><a href='" + NL_DIRECTORY + "native-lang.html'"
+ "title='" + l10n_nav_local_title + "'>" + l10n_nav_local_text + "</a></li>"
Regards,
Jon
> ********************2014-07-03
> >
> > >> 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: marcus.mail@wtnet.de
> > >>> To: l10n@openoffice.apache.org
> > >>> CC: robweir@apache.org; marcus.mail@wtnet.de
> > >>> 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<ol...@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-unsubscribe@openoffice.apache.org
> > >>> For additional commands, e-mail: l10n-help@openoffice.apache.org
> > >>>
> > >>
> >
> >
> >
> > --
> >
> > Ciao
> >
> > Marcus
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: l10n-help@openoffice.apache.org
> >
>
RE: National web sites (Basque)
Posted by Jon Peli Oleaga <ol...@hotmail.com>.
> Date: Wed, 2 Jul 2014 20:57:00 +0200
> From: marcus.mail@wtnet.de
> To: l10n@openoffice.apache.org
> CC: robweir@apache.org; marcus.mail@wtnet.de
> Subject: Re: National web sites (Basque)
>
> Am 07/02/2014 04:33 PM, schrieb Rob Weir:
> > On Wed, Jul 2, 2014 at 6:06 AM, Jon Peli Oleaga<ol...@hotmail.com> 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:
> >
> > http://www.openoffice.org/xx/download/index.html
> >
> > 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] http://www.openoffice.org/eu/softwarea/index.html
> [2] http://www.openoffice.org/download/test/index.html
>
> Marcus
>
********************2014-07-03
If you want to keep in the
localized “sites” the directory structure and file names of the English “site”
perhaps it could be possible in the generated html file instead of
writing;
+
"<h3>"
+ l10n_nav_headline_3_text + "</h3>"
+
"<ul>"
+
"<li><a
href='http://www.openoffice.org/support/index.html'"
+
"title='"
+ l10n_nav_support_title + "'>"
+ l10n_nav_support_text + "</a></li>"
+
"<li><a
href='http://openoffice.apache.org/native-lang.html'"
+
"title='"
+ l10n_nav_local_title + "'>"
+ l10n_nav_local_text + "</a></li>"
to
write
+
"<h3>"
+ l10n_nav_headline_3_text + "</h3>"
+
"<ul>"
+
"<li><a
href='http://www.openoffice.org/" + NL_LANG
+ "/support/index.html'"
+
"title='"
+ l10n_nav_support_title + "'>"
+ l10n_nav_support_text + "</a></li>"
+
"<li><a
href='http://openoffice.apache.org/" + NL_LANG
+ "native-lang.html'"
+
"title='"
+ l10n_nav_local_title + "'>"
+ l10n_nav_local_text + "</a></li>"
and
so on
Jon
********************2014-07-03
>
> >> 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: marcus.mail@wtnet.de
> >>> To: l10n@openoffice.apache.org
> >>> CC: robweir@apache.org; marcus.mail@wtnet.de
> >>> 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<ol...@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-unsubscribe@openoffice.apache.org
> >>> For additional commands, e-mail: l10n-help@openoffice.apache.org
> >>>
> >>
>
>
>
> --
>
> Ciao
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: l10n-help@openoffice.apache.org
>
Re: National web sites (Basque)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/05/2014 10:47 PM, schrieb Marcus (OOo):
> 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<ol...@hotmail.com>
>>> 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:
>>>
>>> http://www.openoffice.org/xx/download/index.html
>>>
>>> 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] http://www.openoffice.org/eu/softwarea/index.html
>> [2] http://www.openoffice.org/download/test/index.html
>
> 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:
>
> l10n_download_error_custom_1_text
> ...
> l10n_download_error_custom_4_text
>
> They have to be used respectivly like the variables:
>
> l10n_download_error_please_select_1_text
> ...
> l10n_download_error_please_select_4_text
>
> Keep them empty to show the default error text.
>
> PS:
> The files in "xx" were updated, too.
any comment to this work? Do you use it already? Anything missing?
Thanks
Marcus
>>>> 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: marcus.mail@wtnet.de
>>>>> To: l10n@openoffice.apache.org
>>>>> CC: robweir@apache.org; marcus.mail@wtnet.de
>>>>> 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<ol...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
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<ol...@hotmail.com>
>> 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:
>>
>> http://www.openoffice.org/xx/download/index.html
>>
>> 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] http://www.openoffice.org/eu/softwarea/index.html
> [2] http://www.openoffice.org/download/test/index.html
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:
l10n_download_error_custom_1_text
...
l10n_download_error_custom_4_text
They have to be used respectivly like the variables:
l10n_download_error_please_select_1_text
...
l10n_download_error_please_select_4_text
Keep them empty to show the default error text.
PS:
The files in "xx" were updated, too.
HTH
Marcus
>>> 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: marcus.mail@wtnet.de
>>>> To: l10n@openoffice.apache.org
>>>> CC: robweir@apache.org; marcus.mail@wtnet.de
>>>> 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<ol...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/02/2014 04:33 PM, schrieb Rob Weir:
> On Wed, Jul 2, 2014 at 6:06 AM, Jon Peli Oleaga<ol...@hotmail.com> 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:
>
> http://www.openoffice.org/xx/download/index.html
>
> 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] http://www.openoffice.org/eu/softwarea/index.html
[2] http://www.openoffice.org/download/test/index.html
Marcus
>> 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: marcus.mail@wtnet.de
>>> To: l10n@openoffice.apache.org
>>> CC: robweir@apache.org; marcus.mail@wtnet.de
>>> 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<ol...@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-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: l10n-help@openoffice.apache.org
>>>
>>
--
Ciao
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by Rob Weir <ro...@apache.org>.
On Wed, Jul 2, 2014 at 6:06 AM, Jon Peli Oleaga <ol...@hotmail.com> 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:
http://www.openoffice.org/xx/download/index.html
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.
Where is this URL defined? How do we customize it so it points to the
same NL version as the topnav version does?
Thanks!
-Rob
> 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: marcus.mail@wtnet.de
>> To: l10n@openoffice.apache.org
>> CC: robweir@apache.org; marcus.mail@wtnet.de
>> 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<ol...@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: l10n-help@openoffice.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
RE: National web sites (Basque)
Posted by Jon Peli Oleaga <ol...@hotmail.com>.
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: marcus.mail@wtnet.de
> To: l10n@openoffice.apache.org
> CC: robweir@apache.org; marcus.mail@wtnet.de
> 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<ol...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: l10n-help@openoffice.apache.org
>
Re: National web sites (Basque)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/01/2014 06:34 PM, schrieb Rob Weir:
> On Tue, Jul 1, 2014 at 8:36 AM, Jon Peli Oleaga<ol...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by Rob Weir <ro...@apache.org>.
On Tue, Jul 1, 2014 at 8:36 AM, Jon Peli Oleaga <ol...@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.
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.
> 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 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?
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by Aivaras Stepukonis <as...@gmail.com>.
I concur. Redirecting visitors to their native subsites from the
homepage should be enough. From that access point, its up to the visitor
how he/she navigates the AOO website.
Regards,
Aivaras
2014.07.06 22:49, Marcus (OOo) rašė:
> IMHO I don't know if we should implement an automatic redirection only
> when the user browses to the main homepage. Of course it's
> convienient. But if you don't want it or explicitely want to see the
> main webpage then you need manual action. For an average user maybe
> not easy.
>
> The other way around is easier - to choose the wished language from
> the drop-down box at top right.
>
> My 2 ct.
>
> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/06/2014 03:41 PM, schrieb Aivaras Stepukonis:
> The part that still needs addressing is how to redirect AOO website
> visitors to their native subsites based on their locale.
>
> Here's a quick example: if I type <http://www.mozilla.org> in the
> browser's address bar I am automatically referred to
> <http://www.mozilla.org/lt> as my locale is Lithuania. This is very
> convenient from a native speaker's point of view. Now, if I do the same
> thing with <http://www.openoffice.org> I am not automatically referred
> to <http://www.openoffice.org/lt>, I can reach the latter destination
> only by manually appending the suffix "lt."
>
> Can the Mozilla scenario be replicated at <http://www.openoffice.org>?
> We could start with the "lt" and "pt" subsites. Others may join
> subsequently whenever they're ready to.
IMHO I don't know if we should implement an automatic redirection only
when the user browses to the main homepage. Of course it's convienient.
But if you don't want it or explicitely want to see the main webpage
then you need manual action. For an average user maybe not easy.
The other way around is easier - to choose the wished language from the
drop-down box at top right.
My 2 ct.
Marcus
> 2014.07.06 16:07, Marcus (OOo) rašė:
>> Am 07/06/2014 01:48 PM, schrieb Aivaras Stepukonis:
>>>> Maybe we have code in the download page that could be reused to guess
>>>> the preferred language and, based on that, redirect "lt" and "pt"
>>>> users to their localized page? If anyone is going to work on that we
>>>> can probably implement it for lt and pt and then, on request, for
>>>> other languages where we have well-maintained subsites.
>>>
>>> This would be great! It is not just about facilitating the use of
>>> information in native languages but also about reassuring the
>>> native-lang teams that their work does not go unnoticed by the very
>>> audiences it was intended for.
>>>
>>>> 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.
>>>
>>> Hm... I actually found the link in the index file of the /lt/download/
>>> page and edited it accordingly. And it worked.
>>
>> great. Is there anything unanswered or do you need still help from me?
>>
>> Thanks
>>
>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by mdx <md...@superposta.com>.
2014-07-07 17:26 GMT+03:00 Rob Weir <ro...@apache.org>:
> On Sun, Jul 6, 2014 at 12:52 PM, Ariel Constenla-Haile
> <ar...@apache.org> wrote:
> > Hello Aivaras Stepukonis,
> >
> > On Sun, Jul 06, 2014 at 04:41:21PM +0300, Aivaras Stepukonis wrote:
> >> The part that still needs addressing is how to redirect AOO website
> visitors
> >> to their native subsites based on their locale.
> >>
> >> Here's a quick example: if I type <http://www.mozilla.org> in the
> browser's
> >> address bar I am automatically referred to <http://www.mozilla.org/lt>
> as my
> >> locale is Lithuania. This is very convenient from a native speaker's
> point
> >> of view. Now, if I do the same thing with <http://www.openoffice.org>
> I am
> >> not automatically referred to <http://www.openoffice.org/lt>, I can
> reach
> >> the latter destination only by manually appending the suffix "lt."
> >>
> >> Can the Mozilla scenario be replicated at <http://www.openoffice.org>?
> >
> > Mozilla uses Python[1] on its server; AFAIK the ASF does not use/allow
> > server-side scripting, so the solution needs to be implemented on the
> > client-side.
> >
>
> Though we should be able to do redirects via Apache HTTP Server and
> mod_rewrite. That can look at request headers and pick out the
> Accept-Language header, right? This assumes the user's browser is
> configured properly.
>
> -Rob
>
> > [1] https://github.com/mozilla/funfactory
> >
> https://github.com/mozilla/funfactory/blob/master/funfactory/urlresolvers.py#L69
> >
> >
> > Regards
> > --
> > Ariel Constenla-Haile
> > La Plata, Argentina
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: l10n-help@openoffice.apache.org
>
>
Re: National web sites (Basque)
Posted by Tal Daniel <ta...@gmail.com>.
I think the same discussion is going in paraller in 2 threads: this one --
"National web sites (Basque)", and in "Website: Detecting Visitor's
Locale". At the latter thread, the notion tends towards using JavaScript
for auto-redirection; that would allow a user to bypass .htaccess
auto-redirection, by using the language dropdown and override the
redirection of the machine from that moment on (on refresh, and future
visits).
I suggest to reply only to the latter thread, since the subject line is
more relevant.
On Mon, Jul 7, 2014 at 9:23 PM, Ariel Constenla-Haile <ar...@apache.org>
wrote:
> On Mon, Jul 07, 2014 at 10:26:07AM -0400, Rob Weir wrote:
> > >> Can the Mozilla scenario be replicated at <http://www.openoffice.org
> >?
> > >
> > > Mozilla uses Python[1] on its server; AFAIK the ASF does not use/allow
> > > server-side scripting, so the solution needs to be implemented on the
> > > client-side.
>
> That should read "AFAIK the ASF does not use/allow server-side scripting
> at project level"; mirrors seem to be handled with a Python script, if
> this is the code
>
> https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/mirrors/mirrors.cgi?view=markup
>
>
> > Though we should be able to do redirects via Apache HTTP Server and
> > mod_rewrite. That can look at request headers and pick out the
> > Accept-Language header, right?
>
> yes, this can even be done in .htaccess (see the tool
> http://www.htaccesstools.com/redirection-by-language/ ); I assume that
> only www.openoffice.org/index.html it planned to be redirected,
> otherwise the whole English content will need to be moved to /en-us/,
> which might break things.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>
--
טל
Re: National web sites (Basque)
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Mon, Jul 07, 2014 at 10:26:07AM -0400, Rob Weir wrote:
> >> Can the Mozilla scenario be replicated at <http://www.openoffice.org>?
> >
> > Mozilla uses Python[1] on its server; AFAIK the ASF does not use/allow
> > server-side scripting, so the solution needs to be implemented on the
> > client-side.
That should read "AFAIK the ASF does not use/allow server-side scripting
at project level"; mirrors seem to be handled with a Python script, if
this is the code
https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/mirrors/mirrors.cgi?view=markup
> Though we should be able to do redirects via Apache HTTP Server and
> mod_rewrite. That can look at request headers and pick out the
> Accept-Language header, right?
yes, this can even be done in .htaccess (see the tool
http://www.htaccesstools.com/redirection-by-language/ ); I assume that
only www.openoffice.org/index.html it planned to be redirected,
otherwise the whole English content will need to be moved to /en-us/,
which might break things.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: National web sites (Basque)
Posted by Rob Weir <ro...@apache.org>.
On Sun, Jul 6, 2014 at 12:52 PM, Ariel Constenla-Haile
<ar...@apache.org> wrote:
> Hello Aivaras Stepukonis,
>
> On Sun, Jul 06, 2014 at 04:41:21PM +0300, Aivaras Stepukonis wrote:
>> The part that still needs addressing is how to redirect AOO website visitors
>> to their native subsites based on their locale.
>>
>> Here's a quick example: if I type <http://www.mozilla.org> in the browser's
>> address bar I am automatically referred to <http://www.mozilla.org/lt> as my
>> locale is Lithuania. This is very convenient from a native speaker's point
>> of view. Now, if I do the same thing with <http://www.openoffice.org> I am
>> not automatically referred to <http://www.openoffice.org/lt>, I can reach
>> the latter destination only by manually appending the suffix "lt."
>>
>> Can the Mozilla scenario be replicated at <http://www.openoffice.org>?
>
> Mozilla uses Python[1] on its server; AFAIK the ASF does not use/allow
> server-side scripting, so the solution needs to be implemented on the
> client-side.
>
Though we should be able to do redirects via Apache HTTP Server and
mod_rewrite. That can look at request headers and pick out the
Accept-Language header, right? This assumes the user's browser is
configured properly.
-Rob
> [1] https://github.com/mozilla/funfactory
> https://github.com/mozilla/funfactory/blob/master/funfactory/urlresolvers.py#L69
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hello Aivaras Stepukonis,
On Sun, Jul 06, 2014 at 04:41:21PM +0300, Aivaras Stepukonis wrote:
> The part that still needs addressing is how to redirect AOO website visitors
> to their native subsites based on their locale.
>
> Here's a quick example: if I type <http://www.mozilla.org> in the browser's
> address bar I am automatically referred to <http://www.mozilla.org/lt> as my
> locale is Lithuania. This is very convenient from a native speaker's point
> of view. Now, if I do the same thing with <http://www.openoffice.org> I am
> not automatically referred to <http://www.openoffice.org/lt>, I can reach
> the latter destination only by manually appending the suffix "lt."
>
> Can the Mozilla scenario be replicated at <http://www.openoffice.org>?
Mozilla uses Python[1] on its server; AFAIK the ASF does not use/allow
server-side scripting, so the solution needs to be implemented on the
client-side.
[1] https://github.com/mozilla/funfactory
https://github.com/mozilla/funfactory/blob/master/funfactory/urlresolvers.py#L69
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: National web sites (Basque)
Posted by Aivaras Stepukonis <as...@gmail.com>.
The part that still needs addressing is how to redirect AOO website
visitors to their native subsites based on their locale.
Here's a quick example: if I type <http://www.mozilla.org> in the
browser's address bar I am automatically referred to
<http://www.mozilla.org/lt> as my locale is Lithuania. This is very
convenient from a native speaker's point of view. Now, if I do the same
thing with <http://www.openoffice.org> I am not automatically referred
to <http://www.openoffice.org/lt>, I can reach the latter destination
only by manually appending the suffix "lt."
Can the Mozilla scenario be replicated at <http://www.openoffice.org>?
We could start with the "lt" and "pt" subsites. Others may join
subsequently whenever they're ready to.
Regards,
Aivaras
2014.07.06 16:07, Marcus (OOo) rašė:
> Am 07/06/2014 01:48 PM, schrieb Aivaras Stepukonis:
>>> Maybe we have code in the download page that could be reused to guess
>>> the preferred language and, based on that, redirect "lt" and "pt"
>>> users to their localized page? If anyone is going to work on that we
>>> can probably implement it for lt and pt and then, on request, for
>>> other languages where we have well-maintained subsites.
>>
>> This would be great! It is not just about facilitating the use of
>> information in native languages but also about reassuring the
>> native-lang teams that their work does not go unnoticed by the very
>> audiences it was intended for.
>>
>>> 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.
>>
>> Hm... I actually found the link in the index file of the /lt/download/
>> page and edited it accordingly. And it worked.
>
> great. Is there anything unanswered or do you need still help from me?
>
> Thanks
>
> Marcus
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/06/2014 01:48 PM, schrieb Aivaras Stepukonis:
>> Maybe we have code in the download page that could be reused to guess
>> the preferred language and, based on that, redirect "lt" and "pt"
>> users to their localized page? If anyone is going to work on that we
>> can probably implement it for lt and pt and then, on request, for
>> other languages where we have well-maintained subsites.
>
> This would be great! It is not just about facilitating the use of
> information in native languages but also about reassuring the
> native-lang teams that their work does not go unnoticed by the very
> audiences it was intended for.
>
>> 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.
>
> Hm... I actually found the link in the index file of the /lt/download/
> page and edited it accordingly. And it worked.
great. Is there anything unanswered or do you need still help from me?
Thanks
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by Aivaras Stepukonis <as...@gmail.com>.
> Maybe we have code in the download page that could be reused to guess
> the preferred language and, based on that, redirect "lt" and "pt"
> users to their localized page? If anyone is going to work on that we
> can probably implement it for lt and pt and then, on request, for
> other languages where we have well-maintained subsites.
This would be great! It is not just about facilitating the use of
information in native languages but also about reassuring the
native-lang teams that their work does not go unnoticed by the very
audiences it was intended for.
> 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.
Hm... I actually found the link in the index file of the /lt/download/
page and edited it accordingly. And it worked.
> Would you like to volunteer to try out this idea for Basque?
I better stay away as much as I can from editing source files. I am
simply underskilled for this task.
Regards,
Aivaras
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/01/2014 06:47 PM, schrieb Andrea Pescetti:
> Aivaras Stepukonis wrote:
>>> What must we do simply to change a bad link in a final “.html” file?
>>
>> Use CMS, edit the html file of your interest (for a native-lang project,
>> usually located in <.../trunk/content/native-lang/...>), then submit,
>> commit, stage, and publish.
>
> This does not work for the download pages. The main download page is
> generated using JavaScript, so you have no "generated" HTML file since
> that is assembled directly in the visitor's browser.
>
> To restrict the conversation to the exact example Jon Peli mentioned,
> the string
> "OpenOffice 4.1.0 is not available in Basque"
> is generated here:
> http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/download/download.js?view=markup
>
> starting from line 545.
>
> In theory one could check the language there and generate a different
> string (with a different order of pieces) for Basque. It is a dangerous
> path to follow, but it may work so long as the exceptions are maintainable.
>
> Otherwise (this would be my favorite, but it would break existing pages
> if not done properly, so CCing Marcus) we could use the bottom part of
> the msg_prop_l10n_XY.js file to store "derived strings" like
>
> var error_not_available = l10n_download_error_aoo_text + VERSION_SEL
> + l10n_download_error_not_available_for_text + "<b>" + RELEASE_LANG[ 1 ]
> + " ("
> + RELEASE_LANG[ 2 ] + ") (" + LANG_SEL + ")</b>.";
>
> so that we have customized versions for those too in the
> msg_prop_l10n_XY.js file.
Yes, could be a way to allow more customization.
However, everybody should keep in mide that this will for sure increase
the complexity again. ;-)
@Aivaras:
Would you like to volunteer to try out this idea for Basque?
I could think of the following way, showing via a source code excerpt:
(I hope that the line breaks do not go mad. ;-) )
// If language is not supported, show the none-availability to the user.
if( ! isLangSupported() ) {
// Show an error message that the chosen items do not lead to a
// download.
var error_text = "<b>" + l10n_download_error_problem_text + "</b>"
+ l10n_download_error_aoo_text + VERSION_SEL
+ l10n_download_error_not_available_for_text + "<b>"
+ RELEASE_LANG[ 1 ] + " (" + RELEASE_LANG[ 2 ] + ")"
+ (" + LANG_SEL + ")</b>."
+ "<br />"
+ "<b>" + l10n_download_error_solution_text + "</b>"
+ l10n_download_error_please_select_4_text;
if( ! l10n_download_error_text_custom_1_text ) {
// Show the error text assembled above.
showErrorMessage( error_text );
} else {
// Show the customized error text from "msg_prop_l10n_XX.js".
showErrorMessage( l10n_download_error_text_custom_1_text );
}
} else {
// If language is supported, assemble the filenames and text for
// download and checksums.
// Go on in "getLinkSel().
}
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by Andrea Pescetti <pe...@apache.org>.
Aivaras Stepukonis wrote:
>> What must we do simply to change a bad link in a final “.html” file?
>
> Use CMS, edit the html file of your interest (for a native-lang project,
> usually located in <.../trunk/content/native-lang/...>), then submit,
> commit, stage, and publish.
This does not work for the download pages. The main download page is
generated using JavaScript, so you have no "generated" HTML file since
that is assembled directly in the visitor's browser.
To restrict the conversation to the exact example Jon Peli mentioned,
the string
"OpenOffice 4.1.0 is not available in Basque"
is generated here:
http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/download/download.js?view=markup
starting from line 545.
In theory one could check the language there and generate a different
string (with a different order of pieces) for Basque. It is a dangerous
path to follow, but it may work so long as the exceptions are maintainable.
Otherwise (this would be my favorite, but it would break existing pages
if not done properly, so CCing Marcus) we could use the bottom part of
the msg_prop_l10n_XY.js file to store "derived strings" like
var error_not_available = l10n_download_error_aoo_text + VERSION_SEL
+ l10n_download_error_not_available_for_text + "<b>" + RELEASE_LANG[
1 ] + " ("
+ RELEASE_LANG[ 2 ] + ") (" + LANG_SEL + ")</b>.";
so that we have customized versions for those too in the
msg_prop_l10n_XY.js file.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by Aivaras Stepukonis <as...@gmail.com>.
Please, see Rob Weir's tutorial
<http://www.youtube.com/watch?v=xcDZN3Lu6HA>.
Regards,
Aivaras
2014.07.01 16:08, Jon Peli Oleaga rašė:
>>> What must we do simply to change a bad link in a final “.html” file?
>> Use CMS, edit the html file of your interest (for a native-lang project,
>> usually located in <.../trunk/content/native-lang/...>), then submit,
>> commit, stage, and publish.
>
> Thanks. What must I do to use CMS?
>
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: l10n-help@openoffice.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org
Re: National web sites (Basque)
Posted by Pedro Albuquerque <pa...@gmail.com>.
Em 01-07-2014 14:08, Jon Peli Oleaga escreveu:
>>> What must we do simply to change a bad link in a final “.html” file?
>> Use CMS, edit the html file of your interest (for a native-lang project,
>> usually located in <.../trunk/content/native-lang/...>), then submit,
>> commit, stage, and publish.
>
> Thanks. What must I do to use CMS?
Hi,
try this Anonymous <http://www.youtube.com/watch?v=7fvg1pfHLhE>
connection. There is another YouTube video from Rob Weir and you can
always search the AOO site for 'ASF CMS'
Regards,
Pedro.
>
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: l10n-help@openoffice.apache.org
>>
>
RE: National web sites (Basque)
Posted by Jon Peli Oleaga <ol...@hotmail.com>.
> > What must we do simply to change a bad link in a final “.html” file?
>
> Use CMS, edit the html file of your interest (for a native-lang project,
> usually located in <.../trunk/content/native-lang/...>), then submit,
> commit, stage, and publish.
Thanks. What must I do to use CMS?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: l10n-help@openoffice.apache.org
>
Re: National web sites (Basque)
Posted by Aivaras Stepukonis <as...@gmail.com>.
> What must we do simply to change a bad link in a final “.html” file?
Use CMS, edit the html file of your interest (for a native-lang project,
usually located in <.../trunk/content/native-lang/...>), then submit,
commit, stage, and publish.
Regards,
Aivaras
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org