Re: Rebuild localisation (Finnish)
Raphael Bircher [r.birc...@gmx.ch] kirjoitti: Am 14.03.12 21:46, schrieb Risto Jääskeläinen: Rob Weir [robw...@apache.org] kirjoitti: On Tue, Feb 28, 2012 at 5:13 AM, rjaas...@saunalahti.fi wrote: Hello from Finland! .. Excellent ! If you can attach your PO files to a Bugzilla issue as well, that will help us get them loaded into Pootle. Or send them to be as an email attachment. .. Regards, -Rob Hello again Now there is bug 119066 where is attachment If you have po files to update pootle please Assignee the issue to rbirc...@apache.org (me) Thanks Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/ Thank you Raphael! Now there is Finnish translations in Pootle at level OOo 3.3 what is latest translation. How to update English part to level AOO 3.4? As I test Nobody can made suggestions but who can approve translations? I think those who have their names in those translation po files are quit secure choice. Regards Risto
Re: Query re possible Release blocker
On 14 March 2012 13:15, Rob Weir robw...@apache.org wrote: On Wed, Mar 14, 2012 at 9:00 AM, Rory O'Farrell ofarr...@iol.ie wrote: On Wed, 14 Mar 2012 12:53:11 + Rory O'Farrell ofarr...@iol.ie wrote: On Wed, 14 Mar 2012 08:36:44 -0400 Rob Weir robw...@apache.org wrote: On Wed, Mar 14, 2012 at 4:51 AM, Ross Gardler rgard...@opendirective.com wrote: I've not experienced this in about a month of reasonably heavy usage. Is there a sure-fire way to trigger the failure? I'd be happy to try it. It looks like Lily is testing with Windows 7 as well. I wonder whether the fact that the upgrade server is down could be currently masking the issue? It regularly failed when the old OOo Upgrade server refused to make a connection, which may have been a factor. I need to stress that the problem only arose after Win7 SP1 was installed; the presence of IE9 on Win7 is sufficient to cause the problem. I'm just trying to find a plausible cause that fits the observed facts: 1) Bug reported before with Windows 7 SP1 and IE9 2) Bug goes away when you disable OOo's automatic updates 2) But bug is not observed in current testing, not in Lily's testing with Windows 7, or with Ross's use. 3) Update server was once working, but is not working now So two plausible theories that are worth testing: A) Bug actually exists in AOO today, but no one is testing with SP1 and IE 9 installed I can confirm that I am running Windows 7 with SP1 and IE9. I can confirm that I have seen no problems with AOO stability in normal use. I can confirm that I've tried to trigger this problem, but that is hard given that we don't have a recipe to reproduce the problem. I have not done any formal testing of AOO, only general use in a reasonably demanding environment. Ross
Re: Query re possible Release blocker
2012/3/14 Rob Weir robw...@apache.org On Wed, Mar 14, 2012 at 9:00 AM, Rory O'Farrell ofarr...@iol.ie wrote: On Wed, 14 Mar 2012 12:53:11 + Rory O'Farrell ofarr...@iol.ie wrote: On Wed, 14 Mar 2012 08:36:44 -0400 Rob Weir robw...@apache.org wrote: On Wed, Mar 14, 2012 at 4:51 AM, Ross Gardler rgard...@opendirective.com wrote: I've not experienced this in about a month of reasonably heavy usage. Is there a sure-fire way to trigger the failure? I'd be happy to try it. It looks like Lily is testing with Windows 7 as well. I wonder whether the fact that the upgrade server is down could be currently masking the issue? It regularly failed when the old OOo Upgrade server refused to make a connection, which may have been a factor. I need to stress that the problem only arose after Win7 SP1 was installed; the presence of IE9 on Win7 is sufficient to cause the problem. I'm just trying to find a plausible cause that fits the observed facts: 1) Bug reported before with Windows 7 SP1 and IE9 2) Bug goes away when you disable OOo's automatic updates 2) But bug is not observed in current testing, not in Lily's testing with Windows 7, or with Ross's use. 3) Update server was once working, but is not working now So two plausible theories that are worth testing: A) Bug actually exists in AOO today, but no one is testing with SP1 and IE 9 installed We tested AOO 3.4 latest dev snap shot build Rev 1299571 with Windows 7 SP1 with IE 9 installed, but couldn't reproduce it. Lily B) Bug actually exists in AOO today, but is masked by the non-availability of the update service We can never prove the absence of a bug, but it is probably worth testing to make sure that neither A nor B lead to a reproducible bug. -Rob -- Rory O'Farrell ofarr...@iol.ie
Re: Let barking dogs bark
On Mar 14, 2012, at 5:54 PM, Carl Marcum wrote: On 03/14/2012 01:22 PM, Jürgen Schmidt wrote: snip For me it shows that some people get nervous because they see that the stuttering engine of AOO runs better and better. So let us oil the engine that it runs constantly and smooth. Juergen +1 After the first AOO release, some of this may end. Well, at least we will be able to address those clueless enough to wonder What has the project been up to these several months... When we do release, we should emphasize how much of an effort it was to do the required due-diligence and alterations to get the IP clearance passed, which was: 1. Non-trivial 2. A benefit to the *entire* OOo ecosystem since it seems that such efforts had not been done for ages. With AOOo, we now have a release that has gone thru intense clearance...
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Hi, On 15.03.2012 12:47, Oliver-Rainer Wittmann wrote: Hi, I have continued the work started by Regina, Ariel and Kay regarding the update service. I have documented my findings at [1]. I think we have everything together to bring a corresponding web service back to life. I think we have at least two options for such a web service. If we want to create a 'real' web service which on demand creates an appropriate response the HTTP GET request contains all needed information in its header fields User-Agent and Accept-Language to implement such a web service. The User-Agent field contains the operating system, the machine architecture and the bundled languages of the installed office. If a corresponding installation package of newer version is available a corresponding response can be generated. Another solution could be to provide a static XML document, based on an atom feed, which contains as much entries as installation packages for the latest version are available. For each installation package which defines itself by the operating system, the machine architecture and the bundled languages an entry is needed. Such entries need to be duplicated for every existing office installation with different UpdateID in its version.ini. Any thoughts, comments, corrections, ...? BTW, the update service of a certain installed office can be tested locally. No HTTP GET request is involved in this case, but you can test with certain XML documents provided as responses. You can change the value of UpdateURL in file version.ini of your office installation to a local file URL - e.g. under Windows to something like file:///C:/check.update.xml [1] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release The UpdateURL in the installed OOo 3.3 instances is http://update36.services.openoffice.org/ProductUpdateService/check.Update. This is no longer available. This also annoys our users I think. If we can redirect this URL and the redirection would provide the following XML document the corresponding update service in these offices will reply your office is up to date The XML document which needs to be provided only has to contain this XML snippet: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://installation.openoffice.org/description; /inst:description Can someone implement the redirect? May be http://www.openoffice.org/ProductUpdateService/check.Update can be used as the redirect. Here, I think it was Kay, already an XML document exists which only needs to be updated. Note: I have also an OOo 3.1 installed. Here the UpdateURL is http://update32.services.openoffice.org/ProductUpdateService/check.Update. May be we should redirect all URL matching http://update3[0..6].services.openoffice.org/ProductUpdateService/check.Update Best regards, Oliver.
Re: AOO for Debian
On Thu, Mar 15, 2012 at 3:58 AM, eric b eric.bach...@free.fr wrote: Hello imacat, Disclaimer : apologies if I do not answer regularly, but I don't have much of free time at the moment (my day job ...) Le 15 mars 12 à 00:32, imacat a écrit : I was thinking about this, too. Great :-) FYI, OOo4Kids and OOoLight are available under the .deb form, on our own unofficial repository (http on EducOOo serverp). We did that, because Debian people refused to add OOo4Kids in the Debian build farm, because I (me) refused to use LibreOffice sources. Nothing else, and this is the same problem for Apache OpenOffice. FYI, Ubuntu Mageia, Mandriva blocked us too : while issues asking for integration exist, nobody will never do anything serious, and every time we'll fit a condition, another will be invented to block again ... The only nice distribution who accepted us, is ArchLinux, and you can install OOo4Kids on it, like you can still install OpenOffice.org on ArchLinux if you want. Back to the .deb, the one I build installs perfectly (incuing using apt-get, synaptic and so on) in parallel with everything, and caused no trouble until now. Both are created the deb way (using dh_make), and I'll explain you how. The initial work has been done by a student from Epitech Paris, Mathias Brunet (alia Kaze, you probably meet on IRC some time ago). Mathias created the initial script (was his contribution to EducOOo for his project), and since, I maintain it. The current process is manual, but all this work can certainly be automatized and ported to Apache OpenOffice. Nevertheless, we'll need to make it more profesional before. First, the desktop part ( in sysui ) is built the same way during the dmake process, excepted that we replace /opt with /usr in the install path, and add our own stuff. Second, using installed package format + a new one I named debian, I build final .deb using a shell script. During the process, we modify everything to respect the FHS way. The final archive contains everything, including menu entries. My day job is killing me at the moment, but in two weeks, I'll have more free time. Waiting, if you want to work on that, I can forward you everything and help you from time to time on IRC. But actually, for this to work, the discussion should be brought to the debian-openoff...@lists.debian.org list, not debian-u...@lists.debian.org. Also we need someone understand how to package .deb packages that follow the Debian policy in order to package AOO by the Debian policy. Long time ago, Rene Engelhard subscribed me to the list, and I know well what happens, since I receive everything (a lot of mails indeed .. ). Not sure I can post though, but read is ok for me. And I'm aware of your requests ... and of Rene answers too :-/ For the long term, we should update our build system so it follows the Filesystem Hierarchy Standard (FHS) and meets the requirements of the distributions. IMHO, porting to Debian is not the problem, I got scripts doing this already, who could be adapted to Apache OOo (one or two days of work max to create an .deb of Apache OO ). The problem is that there is a lobby blocking the process, and avoiding Apache OpenOffice being existing in Debian, even on other distributions. The only fair distribution who accepted to keep things working (you can stilll build OpenOffice.org yourself if you want) is ArchLinux, as I wrote above. I think that is the easy part. But we need to meet the technical requirements first. Otherwise it will look very bad for Debian. What next? Block AbiWord and Gnumeric because they compete with LibreOffice? One more time back to ex-Community Members blocking everything coming from apache OpenOffice. Regards, Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: update service - further information for such a service
On Thu, Mar 15, 2012 at 7:47 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, I have continued the work started by Regina, Ariel and Kay regarding the update service. I have documented my findings at [1]. I think we have everything together to bring a corresponding web service back to life. I think we have at least two options for such a web service. If we want to create a 'real' web service which on demand creates an appropriate response the HTTP GET request contains all needed information in its header fields User-Agent and Accept-Language to implement such a web service. The User-Agent field contains the operating system, the machine architecture and the bundled languages of the installed office. If a corresponding installation package of newer version is available a corresponding response can be generated. Another solution could be to provide a static XML document, based on an atom feed, which contains as much entries as installation packages for the latest version are available. For each installation package which defines itself by the operating system, the machine architecture and the bundled languages an entry is needed. Such entries need to be duplicated for every existing office installation with different UpdateID in its version.ini. Any thoughts, comments, corrections, ...? My opinion: This is an example of a low rate of change application. The data changes every few weeks or months, not daily or hourly. It is also a high traffic service, especially when we have millions of clients doing automatic update checks. So a static file is probably better for server load/performance. I wonder if the static XML file could be automatically generated via a script? Maybe part of our release script? (I assume we'll eventually have a release script that deals with cutting RC's, doing the code signing, etc.) BTW, the update service of a certain installed office can be tested locally. No HTTP GET request is involved in this case, but you can test with certain XML documents provided as responses. You can change the value of UpdateURL in file version.ini of your office installation to a local file URL - e.g. under Windows to something like file:///C:/check.update.xml [1] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release
Re: Pootle translation roundtrip
On 3/14/12 8:28 PM, Claudio Filho wrote: Hi 2012/3/14 Jürgen Schmidtjogischm...@googlemail.com Am Mittwoch, 14. März 2012 schrieb Claudio Filhofilh...@gmail.com: Jürgen, you wish to say words or strings? How many *strings* (lines) have the last SDF? Pootle counts 89977 words. But I have seen for example a file/section with 2 entries counting 5 words together. Means 2 commits for 5 words. Exact. I uploaded the PO template generated from your en-US.sdf to Pootle (in my machine) and matches with your. It says that have 89977 words, so we have 72696 strings (with 89977 words). This is a mistake that happen between professional and volunteers translators. The first charges by word, and the second don't charge. :-P Now, serious, for volunteers, generally we see how many strings need to translate, where can be since one symbol or a phrase of 10 lines. Well, now i see that is all ok. I included your po files in my local Pootle server and it looks good so far, 100% complete thanks a lot. I will test the roundtrip when I have updated a few German strings becasue I understand German a little bit better ;-) I integrated Czech also in my local Pootle server and it looks also not bad, 1264 words needs translation. Pavel volunteered to take a look on it. Juergen
Re: update service - further information for such a service
Hi Oliver,
On Thu, Mar 15, 2012 at 12:47:41PM +0100, Oliver-Rainer Wittmann wrote:
Hi,
I have continued the work started by Regina, Ariel and Kay regarding
the update service.
I have documented my findings at [1].
I think we have everything together to bring a corresponding web
service back to life.
I think we have at least two options for such a web service.
If we want to create a 'real' web service which on demand creates an
appropriate response the HTTP GET request contains all needed
information in its header fields User-Agent and Accept-Language
to implement such a web service.
The User-Agent field contains the operating system, the machine
architecture and the bundled languages of the installed office. If a
corresponding installation package of newer version is available a
corresponding response can be generated.
Another solution could be to provide a static XML document, based on
an atom feed, which contains as much entries as installation
packages for the latest version are available. For each installation
package which defines itself by the operating system, the machine
architecture and the bundled languages an entry is needed. Such
entries need to be duplicated for every existing office installation
with different UpdateID in its version.ini.
Any thoughts, comments, corrections, ...?
All seems right. One missing point is the query part of the URL,
a non-WNT feature related to the package format, see
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/scp2/source/ooo/common_brand.scp?revision=1296424view=markup#l1031
${UPDATEURL}?pkgfmt=pkgformat
A web service should analyze the query string, pkgfmt can be rpm or deb
(in a common Linux install set).
BTW, the update service of a certain installed office can be tested
locally. No HTTP GET request is involved in this case, but you can
test with certain XML documents provided as responses. You can
change the value of UpdateURL in file version.ini of your office
installation to a local file URL - e.g. under Windows to something
like file:///C:/check.update.xml
[1]
http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
pgporbabzkWZO.pgp
Description: PGP signature
Re: update service - further information for such a service
Hi,
All seems right. One missing point is the query part of the URL,
a non-WNT feature related to the package format, see
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/scp2/source/ooo/common_brand.scp?revision=1296424view=markup#l1031
${UPDATEURL}?pkgfmt=pkgformat
A web service should analyze the query string, pkgfmt can be rpm or deb
(in a common Linux install set).
the former Product Update Service differentiated between update URLs
pointing to a binary location and update notifications that pointed to a
landing page. In case of a binary location the pkg format is used to
differ between sh (Self extracting binary as UNIX shell script), rpm and
deb (Linux), dmg (Mac) and exe (Win32) for binaries. The name scheme of
binary distributions is also important to get things automated.
see http://www.openoffice.org/development/releases/filenames
Kind regards, Joost
Re: update service - further information for such a service
Hi,
On 15.03.2012 14:20, Ariel Constenla-Haile wrote:
Hi Oliver,
On Thu, Mar 15, 2012 at 12:47:41PM +0100, Oliver-Rainer Wittmann wrote:
Hi,
I have continued the work started by Regina, Ariel and Kay regarding
the update service.
I have documented my findings at [1].
I think we have everything together to bring a corresponding web
service back to life.
I think we have at least two options for such a web service.
If we want to create a 'real' web service which on demand creates an
appropriate response the HTTP GET request contains all needed
information in its header fields User-Agent and Accept-Language
to implement such a web service.
The User-Agent field contains the operating system, the machine
architecture and the bundled languages of the installed office. If a
corresponding installation package of newer version is available a
corresponding response can be generated.
Another solution could be to provide a static XML document, based on
an atom feed, which contains as much entries as installation
packages for the latest version are available. For each installation
package which defines itself by the operating system, the machine
architecture and the bundled languages an entry is needed. Such
entries need to be duplicated for every existing office installation
with differentUpdateID in its version.ini.
Any thoughts, comments, corrections, ...?
All seems right. One missing point is the query part of the URL,
a non-WNT feature related to the package format, see
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/scp2/source/ooo/common_brand.scp?revision=1296424view=markup#l1031
${UPDATEURL}?pkgfmt=pkgformat
A web service should analyze the query string, pkgfmt can be rpm or deb
(in a common Linux install set).
Thanks for the pointer - I will update the wiki.
For a static approach it would mean that we would not have the possibility to
provide a download link for Linux platforms. In this case we could only provide
a download website.
For the MacOS X platform we only have pkgformat=dmg. Right?
If yes, a static approach could also provide a download link.
Best regards, Oliver.
BTW, the update service of a certain installed office can be tested
locally. No HTTP GET request is involved in this case, but you can
test with certain XML documents provided as responses. You can
change the value ofUpdateURL in fileversion.ini of your office
installation to a local file URL - e.g. under Windows to something
like file:///C:/check.update.xml
[1]
http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release
Regards
Re: Doctype of websites
On Mar 15, 2012, at 12:22 AM, Regina Henschel wrote: Hi, Joe Schaefer schrieb: From: Regina Henschelrb.hensc...@t-online.de To: ooo-dev@incubator.apache.org Sent: Tuesday, March 13, 2012 5:31 PM Subject: Re: Doctype of websites Hi Joe, Joe Schaefer schrieb: Those de.openoffice.org pages should redirect to www.openoffice.org/de pages, if not your DNS resolver is busted. I had indeed set de.openoffice.org to 192.9.163.104. Removing it makes redirecting work. That means the pages at de.openoffice.org had been the original ones, but will be deleted in near future. They had been imported to ooo-site.apache.org/de and here they have got a different doctype. Right? Well sort of. If you look at the actual document on the site you will probably find it contains an XHTML doctype even now. The thing is that the CMS build system as Dave has designed it will strip most of the header matter out of the file and replace it with a generic one supplied by a template. If that's not the problem then you need to refresh your pages as they are identical on the server. As to why the doctype is different from the original document, that's probably due to the way Dave worked out the templates for the site. If we need to scrape the doctype out of each individual page that will require some perl coding work, some templating work, and another sledgehammer style commit- ie not something to be taken lightly. Our pages had been XHTML with all the differences to HTML. And we tried to produce valid pages (including W3C check button). It is not impossible to change the pages and it can be done bit by bit while reviewing the pages. But the aim should be clear. Well I can't advise you how to proceed from here, only point out that there is some impedance mismatch between how your site builds work and what's actually in these documents. The choice seems to be either standardize all the documents on a common doctype or have the perl code pull the doctype out of the original document if it exists and pass it along to the template as an argument. You might even be better off just not supplying a doctype at all and letting the browser figure it out. Up to you folks. If we want valid pages, a common doctype is needed because the inserted part has to be written in a way, that it fits this doctype. For example you need for the feather-logo an img .../ element in XHTML and in HTML only img So I think we need to agree on one doctype. Is it possible to count, how many pages of all are actually having an XHTML doctype? (I'm not familiar with command line.) Kind regards Regina P.S. The feather img-Element is missing the alt-attribute. I have been looking into this. In general the skeleton is the non-compliant part and is what should be changed. However there are many of the NLC sites that are very much HTML. One more sledgehammer will happen ... but planning needs to be careful. Regards, Dave
Re: Doctype of websites
On Thu, Mar 15, 2012 at 10:33 AM, Dave Fisher dave2w...@comcast.net wrote: On Mar 15, 2012, at 12:22 AM, Regina Henschel wrote: Hi, Joe Schaefer schrieb: From: Regina Henschelrb.hensc...@t-online.de To: ooo-dev@incubator.apache.org Sent: Tuesday, March 13, 2012 5:31 PM Subject: Re: Doctype of websites Hi Joe, Joe Schaefer schrieb: Those de.openoffice.org pages should redirect to www.openoffice.org/de pages, if not your DNS resolver is busted. I had indeed set de.openoffice.org to 192.9.163.104. Removing it makes redirecting work. That means the pages at de.openoffice.org had been the original ones, but will be deleted in near future. They had been imported to ooo-site.apache.org/de and here they have got a different doctype. Right? Well sort of. If you look at the actual document on the site you will probably find it contains an XHTML doctype even now. The thing is that the CMS build system as Dave has designed it will strip most of the header matter out of the file and replace it with a generic one supplied by a template. If that's not the problem then you need to refresh your pages as they are identical on the server. As to why the doctype is different from the original document, that's probably due to the way Dave worked out the templates for the site. If we need to scrape the doctype out of each individual page that will require some perl coding work, some templating work, and another sledgehammer style commit- ie not something to be taken lightly. Our pages had been XHTML with all the differences to HTML. And we tried to produce valid pages (including W3C check button). It is not impossible to change the pages and it can be done bit by bit while reviewing the pages. But the aim should be clear. Well I can't advise you how to proceed from here, only point out that there is some impedance mismatch between how your site builds work and what's actually in these documents. The choice seems to be either standardize all the documents on a common doctype or have the perl code pull the doctype out of the original document if it exists and pass it along to the template as an argument. You might even be better off just not supplying a doctype at all and letting the browser figure it out. Up to you folks. If we want valid pages, a common doctype is needed because the inserted part has to be written in a way, that it fits this doctype. For example you need for the feather-logo an img .../ element in XHTML and in HTML only img So I think we need to agree on one doctype. Is it possible to count, how many pages of all are actually having an XHTML doctype? (I'm not familiar with command line.) Kind regards Regina P.S. The feather img-Element is missing the alt-attribute. I have been looking into this. In general the skeleton is the non-compliant part and is what should be changed. However there are many of the NLC sites that are very much HTML. One more sledgehammer will happen ... but planning needs to be careful. What if we went subdomain by subdomain and ran HTML Tidy on the content to coerce it to a single doctype. Would that butcher things? -Rob Regards, Dave
Re: AOO for Debian
On 03/15/12 02:58, eric b wrote: ... But actually, for this to work, the discussion should be brought to the debian-openoff...@lists.debian.org list, not debian-u...@lists.debian.org. Also we need someone understand how to package .deb packages that follow the Debian policy in order to package AOO by the Debian policy. Long time ago, Rene Engelhard subscribed me to the list, and I know well what happens, since I receive everything (a lot of mails indeed .. ). Not sure I can post though, but read is ok for me. And I'm aware of your requests ... and of Rene answers too :-/ I read Rene's position and if it's really technically impossible to have both LibreOffice and Apache OpenOffice in Debian then I would think that proves, yet again, that FreeBSD is technically superior to Debian. (not to talk about freedom just yet ;) ) BTW, I am pretty sure that we would like to have OOoLight and OOoKids in FreeBSD and it shouldn't be difficult to use the current AOO port as a template. I am extremely busy at this time but it would surely be something to consider. Pedro.
Re: Clarifying facts
On 2012-03-14 1:23 AM, Larry Gusaas wrote: On 2012-03-13 10:43 PM Rob Weir wrote: I disagree entirely. Simon was the one apply the blunt instrument here. He started the day by posting on Google+: Since there is no currently maintained version of OpenOffice.org following Oracle disbanding the team, and since the new Apache OpenOffice hasn't shipped, defaulting to LibreOffice is the only responsible thing to do at the moment. Link please. I couldn't find it. The quote above comes from Simon on this Google+ comment thread: https://plus.google.com/u/0/107646708505179576030/posts/ViuT8bLgz2p It seems like that thread is public so you should be able to click through and see some more arguments over the issue as well. - Shane P.S. For those who might actually be reading this but are otherwise new to open source projects at Apache, please realize that AOO is not the norm for Apache projects in terms of the incredible volume of mail traffic, nor in terms of continued poor behavior patterns played out here with some regularity.
Re: AOO for Debian
On Thu, Mar 15, 2012 at 10:56 AM, Pedro Giffuni p...@apache.org wrote: On 03/15/12 02:58, eric b wrote: ... But actually, for this to work, the discussion should be brought to the debian-openoff...@lists.debian.org list, not debian-u...@lists.debian.org. Also we need someone understand how to package .deb packages that follow the Debian policy in order to package AOO by the Debian policy. Long time ago, Rene Engelhard subscribed me to the list, and I know well what happens, since I receive everything (a lot of mails indeed .. ). Not sure I can post though, but read is ok for me. And I'm aware of your requests ... and of Rene answers too :-/ I read Rene's position and if it's really technically impossible to have both LibreOffice and Apache OpenOffice in Debian then I would think that proves, yet again, that FreeBSD is technically superior to Debian. (not to talk about freedom just yet ;) ) I would not give up yet. I think that with some gentle and friendly conversations we can persuade the distros that users should have choice, even on Linux. BTW, I am pretty sure that we would like to have OOoLight and OOoKids in FreeBSD and it shouldn't be difficult to use the current AOO port as a template. I am extremely busy at this time but it would surely be something to consider. Pedro.
Re: Doctype of websites
On Mar 15, 2012, at 7:37 AM, Rob Weir wrote: On Thu, Mar 15, 2012 at 10:33 AM, Dave Fisher dave2w...@comcast.net wrote: On Mar 15, 2012, at 12:22 AM, Regina Henschel wrote: Hi, Joe Schaefer schrieb: From: Regina Henschelrb.hensc...@t-online.de To: ooo-dev@incubator.apache.org Sent: Tuesday, March 13, 2012 5:31 PM Subject: Re: Doctype of websites Hi Joe, Joe Schaefer schrieb: Those de.openoffice.org pages should redirect to www.openoffice.org/de pages, if not your DNS resolver is busted. I had indeed set de.openoffice.org to 192.9.163.104. Removing it makes redirecting work. That means the pages at de.openoffice.org had been the original ones, but will be deleted in near future. They had been imported to ooo-site.apache.org/de and here they have got a different doctype. Right? Well sort of. If you look at the actual document on the site you will probably find it contains an XHTML doctype even now. The thing is that the CMS build system as Dave has designed it will strip most of the header matter out of the file and replace it with a generic one supplied by a template. If that's not the problem then you need to refresh your pages as they are identical on the server. As to why the doctype is different from the original document, that's probably due to the way Dave worked out the templates for the site. If we need to scrape the doctype out of each individual page that will require some perl coding work, some templating work, and another sledgehammer style commit- ie not something to be taken lightly. Our pages had been XHTML with all the differences to HTML. And we tried to produce valid pages (including W3C check button). It is not impossible to change the pages and it can be done bit by bit while reviewing the pages. But the aim should be clear. Well I can't advise you how to proceed from here, only point out that there is some impedance mismatch between how your site builds work and what's actually in these documents. The choice seems to be either standardize all the documents on a common doctype or have the perl code pull the doctype out of the original document if it exists and pass it along to the template as an argument. You might even be better off just not supplying a doctype at all and letting the browser figure it out. Up to you folks. If we want valid pages, a common doctype is needed because the inserted part has to be written in a way, that it fits this doctype. For example you need for the feather-logo an img .../ element in XHTML and in HTML only img So I think we need to agree on one doctype. Is it possible to count, how many pages of all are actually having an XHTML doctype? (I'm not familiar with command line.) Kind regards Regina P.S. The feather img-Element is missing the alt-attribute. I have been looking into this. In general the skeleton is the non-compliant part and is what should be changed. However there are many of the NLC sites that are very much HTML. One more sledgehammer will happen ... but planning needs to be careful. What if we went subdomain by subdomain and ran HTML Tidy on the content to coerce it to a single doctype. Would that butcher things? We have a file called content/brand.mdtext that controls the branding language and logo for each page. In templates we have templates/ssi.mdtext and templates/api/ssi.mdtext David-Fishers-MacBook-Air:templates dave$ more ssi.mdtext brand: /brand.html footer: /footer.html topnav: /topnav.html home: home I think that ssi.mdtext should add a line like: doctype:!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; And if mn needs a different treatment: templates/mn/ssi.mdtext brand: /mn/brand.html footer: /footer.html topnav: /mn//topnav.html home: home doctype: This fits the NL plan. I want to avoid divergent skeleton.html files, and it may be the case that some sections will want an xhtml skeleton while others get a html. I still intend to avoid changing every file. I've $job to pay attention to until late today ... sorry that I'm dribbling out these plans bit by bit. Regards, Dave -Rob Regards, Dave
Re: [MIGRATION] Shut down on remaining Oracle web resources
On Wed, Mar 14, 2012 at 10:09 PM, Rob Weir robw...@apache.org wrote: On Wed, Mar 14, 2012 at 4:54 PM, Roberto Galoppini rgalopp...@geek.net wrote: On Wed, Mar 14, 2012 at 6:02 AM, Rob Weir robw...@apache.org wrote: On Mon, Mar 12, 2012 at 10:06 PM, Andrew Rist andrew.r...@oracle.com wrote: On 3/12/2012 5:27 PM, Rob Weir wrote: On Wed, Feb 22, 2012 at 12:14 AM, Andrew Ristandrew.r...@oracle.com wrote: I would like to set the date for shutting down these Oracle hosted resources as March 15. (no Shakespeare references, please) This will include mailing lists, mail forwarder, remaining web pages, identity server. What are people's thoughts on this? (sooner is possible, I believe) Hi Andrew, Would it be possible to get one more blast out to the legacy announcement list before we shut it down? Sure - I can do that. If so, I can craft a short note, directing them to the new lists, etc. That would be great. How about something like this: = Subject: Final Reminder on OpenOffice.org mailing list and email forwarder shutdown Please note that the legacy mailing lists for the OpenOfficeOffice.org project will be retired effective March 16h. New mailing lists have been created, at Apache, for users as well as project participants. If you wish to continue to receive occasional email updates from the project, for new releases,etc., then please subscribe to our announcement email list by sending an email to ooo-announce-subscr...@incubator.apache.org. Information on other mailing lists for the project can be found here: http://incubator.apache.org/openofficeorg/mailing-lists.html Also on March 16th we will shutdown the legacy email forwarder for the openoffice.org domain. If you have and use an openoffice.org email address alias, then please note the important information described on the following page: https://blogs.apache.org/OOo/entry/retirement_of_openoffice_org_email Rob, maybe we could update that blog entry adding some info about Extensions/Templates accounts in the Some special instructions for OpenOffice-related services section? Starting from tomorrow Extensions and Templates users authenticating at openoffice.org won't be able to access those systems. As I explained in another thread we need to get some info to recreate those accounts and allow users to change their passwords. Sure.. What do you want me to add to that post? Are there some specific instructions? -Rob We might instruct users that to convert their accounts they just need to enter their openoffice.org username and password and ask them to read the messages shown. If they do not remember the password, the link Request new password pages http://extensions.services.openoffice.org/user http://templates.services.openoffice.org/user allows them to receive a link to change e-mail address and password (note that the two websites use different logins). Note that the request new password will work until the @openoffice.org alias will be active. Last but not least, the possibility to use the old password will work until the Oracle authentication server is operational. VERY IMPORTANT: Consider that both kiling the alias forwarding and shutting down the Oracle authentication server will prevent users to login. I hope we can keep alive at least one of those services at least until we'll get from Oracle all necessary information to migrate users. Roberto Roberto We thank you for your past interest and support of the OpenOffice.org project and look forward to your continued support at Apache. Rob Weir, on behalf of the Apache OpenOffice Project Management Committee = If this still makes sense in the morning, we can go with that or something similar. Do you need to send it, or would I send it and then you moderate me in? -Rob A. -Rob Andrew This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you. This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
Re: AOO for Debian
Hi Pedro, Le 15 mars 12 à 15:56, Pedro Giffuni a écrit : On 03/15/12 02:58, eric b wrote: ... But actually, for this to work, the discussion should be brought to the debian-openoff...@lists.debian.org list, not debian-u...@lists.debian.org. Also we need someone understand how to package .deb packages that follow the Debian policy in order to package AOO by the Debian policy. Long time ago, Rene Engelhard subscribed me to the list, and I know well what happens, since I receive everything (a lot of mails indeed .. ). Not sure I can post though, but read is ok for me. And I'm aware of your requests ... and of Rene answers too :-/ I read Rene's position and if it's really technically impossible to have both LibreOffice and Apache OpenOffice in Debian There could be duplicated installed stuff, but since OOo4Kids installs fine on any Debian or derivative with LO, I bet this is possible :-) then I would think that proves, yet again, that FreeBSD is technically superior to Debian. (not to talk about freedom just yet ;) ) Ha ha :-) BTW, I am pretty sure that we would like to have OOoLight and OOoKids in FreeBSD and it shouldn't be difficult to use the current AOO port as a template. Not sure. I'll have to adapt a lot of things first. I am extremely busy at this time but it would surely be something to consider. There will be a lot of work before : our derivative products are based on OOo 3.2.1 source code, and I prefer use dmake instead of gnu make, who mainly added problems and solved nothing important (to my eyes, but I can be wrong). So the patch will be big, but I already did it at the begining. What I could do is align OOo4kids with AOOo (this is two weeks of work at least) and provide patches for the missing makefiles and so on. The localization will need some love too : in OOo4Kids, I modified the makefiles to use localized.sdf + localized-$application.sdf ($application can contain OOo4kids or OOo or OOoLight) files, and I even added localized-OOo.sdf in case we backport a day the new strings we added in OOo4Kids. e.g : localize-OOo.sdflocalize-OOo4Kids.sdf localize- OOoLight.sdf localize.sdf exist for all the supported locales. localize.sdf contains only old 3.2.1 stuff, less what has been modified. I got a process to build new .sdf from scratch. Not perfect (even hackish), but works very well at least for the 18 locales we provide. Suggestion : as improvement, I'd suggest to use the same process for new strings, introducing localize-New.sdf or something similar in AOOo. The idea is to separate the new strings from the other older one (introducing a safer build system), and to progressively integrate new stuff. e.g. once all strings are ok, and no regression is detected, then integrate the NEW into the old localize.sdf. Other interest : the new strings integration process could be done asynchronously with the release, and decoupled for every locale. But that's just a suggestion ;-) Back to FreeBSD : as answer, I know the build is currently possible on OpenBSD (not tested since a while). FYI, I even wrote a port file (untested, probably buggy), but so far, nobody reported anything on FreeBSD yet, but there is no reason it won't work. To be continued ;-) Eric -- qɔᴉɹə Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page L'association EducOOo : http://www.educoo.org Blog : http://eric.bachard.org/news
Re: Doctype of websites
Hi Dave, *, probably one of my last messages on the list since I'll be gone with the forwarder.. (so assume I will not read replies tomorrow/whenever the switch is flipped) On Thu, Mar 15, 2012 at 4:32 PM, Dave Fisher dave2w...@comcast.net wrote: On Mar 15, 2012, at 7:37 AM, Rob Weir wrote: On Thu, Mar 15, 2012 at 10:33 AM, Dave Fisher dave2w...@comcast.net wrote: On Mar 15, 2012, at 12:22 AM, Regina Henschel wrote: [...] Well sort of. If you look at the actual document on the site you will probably find it contains an XHTML doctype even now. Old OOo pages were xhtml transitional, that is correct. And at least the www.openoffice.org and de.openoffice.org pages were fully valid (according to the w3c validator) CollabNet Enterprise Edition (that was used before Kenai, and after SourceCast (the old name of older version of CollabNet Enterprise Edition that was used even earlier) did as well ignore the doctype and other meta-tags, but merged title and meta tags into the overall templating system. So all pages were delivered as xhtml - of course that didn't make them valid, but that means that they worked for the users and editors with that doctype. [...] I think that ssi.mdtext should add a line like: doctype: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; Please don't turn back the wheel of time. If you want to make a unification, then I suggest you either user xhtml transitional, or make the step to html5 right away as default. ciao Christian
Re: Doctype of websites
On Mar 15, 2012, at 8:41 AM, Christian Lohmaier wrote: Hi Dave, *, probably one of my last messages on the list since I'll be gone with the forwarder.. (so assume I will not read replies tomorrow/whenever the switch is flipped) On Thu, Mar 15, 2012 at 4:32 PM, Dave Fisher dave2w...@comcast.net wrote: On Mar 15, 2012, at 7:37 AM, Rob Weir wrote: On Thu, Mar 15, 2012 at 10:33 AM, Dave Fisher dave2w...@comcast.net wrote: On Mar 15, 2012, at 12:22 AM, Regina Henschel wrote: [...] Well sort of. If you look at the actual document on the site you will probably find it contains an XHTML doctype even now. Old OOo pages were xhtml transitional, that is correct. And at least the www.openoffice.org and de.openoffice.org pages were fully valid (according to the w3c validator) CollabNet Enterprise Edition (that was used before Kenai, and after SourceCast (the old name of older version of CollabNet Enterprise Edition that was used even earlier) did as well ignore the doctype and other meta-tags, but merged title and meta tags into the overall templating system. So all pages were delivered as xhtml - of course that didn't make them valid, but that means that they worked for the users and editors with that doctype. [...] I think that ssi.mdtext should add a line like: doctype:!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; Please don't turn back the wheel of time. If you want to make a unification, then I suggest you either user xhtml transitional, or make the step to html5 right away as default. Thanks. In my limited testing yesterday the W3C validator very much liked HTML5. Regards, Dave ciao Christian
HTML 5 Re: Doctype of websites
Please consider HTML5 - which is much easier and will soon be the standard. I have not figured out how to make the template changes in OpenOffice, but if someone is doing that - this format leads to the future. Basically HTML5 means everything that is new in HTML - it is not the standard 'yet' but will be very soon. Something to consider - W3Schools explains code format : http://www.w3schools.com/html5/html5_intro.asp !DOCTYPE html html head titleTitle of the document/title /head body The content of the document.. /body /html W3C Dev Editors draft updated daily: http://dev.w3.org/html5/spec/Overview.html Doctype explained: W3C schools http://www.w3schools.com/html5/tag_doctype.asp HTML5 API File features http://www.html5rocks.com/en/features/file_access Nancy Web Design Free 24 hour pass to lynda.com. Video courses on SEO, CMS, Design and Software Courses From: Dave Fisher dave2w...@comcast.net To: ooo-dev@incubator.apache.org Sent: Thursday, March 15, 2012 8:32 AM Subject: Re: Doctype of websites On Mar 15, 2012, at 7:37 AM, Rob Weir wrote: On Thu, Mar 15, 2012 at 10:33 AM, Dave Fisher dave2w...@comcast.net wrote: On Mar 15, 2012, at 12:22 AM, Regina Henschel wrote: Hi, Joe Schaefer schrieb: From: Regina Henschelrb.hensc...@t-online.de To: ooo-dev@incubator.apache.org Sent: Tuesday, March 13, 2012 5:31 PM Subject: Re: Doctype of websites Hi Joe, Joe Schaefer schrieb: Those de.openoffice.org pages should redirect to www.openoffice.org/de pages, if not your DNS resolver is busted. I had indeed set de.openoffice.org to 192.9.163.104. Removing it makes redirecting work. That means the pages at de.openoffice.org had been the original ones, but will be deleted in near future. They had been imported to ooo-site.apache.org/de and here they have got a different doctype. Right? Well sort of. If you look at the actual document on the site you will probably find it contains an XHTML doctype even now. The thing is that the CMS build system as Dave has designed it will strip most of the header matter out of the file and replace it with a generic one supplied by a template. If that's not the problem then you need to refresh your pages as they are identical on the server. As to why the doctype is different from the original document, that's probably due to the way Dave worked out the templates for the site. If we need to scrape the doctype out of each individual page that will require some perl coding work, some templating work, and another sledgehammer style commit- ie not something to be taken lightly. Our pages had been XHTML with all the differences to HTML. And we tried to produce valid pages (including W3C check button). It is not impossible to change the pages and it can be done bit by bit while reviewing the pages. But the aim should be clear. Well I can't advise you how to proceed from here, only point out that there is some impedance mismatch between how your site builds work and what's actually in these documents. The choice seems to be either standardize all the documents on a common doctype or have the perl code pull the doctype out of the original document if it exists and pass it along to the template as an argument. You might even be better off just not supplying a doctype at all and letting the browser figure it out. Up to you folks. If we want valid pages, a common doctype is needed because the inserted part has to be written in a way, that it fits this doctype. For example you need for the feather-logo an img .../ element in XHTML and in HTML only img So I think we need to agree on one doctype. Is it possible to count, how many pages of all are actually having an XHTML doctype? (I'm not familiar with command line.) Kind regards Regina P.S. The feather img-Element is missing the alt-attribute. I have been looking into this. In general the skeleton is the non-compliant part and is what should be changed. However there are many of the NLC sites that are very much HTML. One more sledgehammer will happen ... but planning needs to be careful. What if we went subdomain by subdomain and ran HTML Tidy on the content to coerce it to a single doctype. Would that butcher things? We have a file called content/brand.mdtext that controls the branding language and logo for each page. In templates we have templates/ssi.mdtext and templates/api/ssi.mdtext David-Fishers-MacBook-Air:templates dave$ more ssi.mdtext brand: /brand.html footer: /footer.html topnav: /topnav.html home: home I think that ssi.mdtext should add a line like: doctype: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; And if mn needs a different treatment: templates/mn/ssi.mdtext brand: /mn/brand.html footer: /footer.html
Re: update service - further information for such a service
On Thu, Mar 15, 2012 at 5:52 AM, Rob Weir robw...@apache.org wrote: On Thu, Mar 15, 2012 at 7:47 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, I have continued the work started by Regina, Ariel and Kay regarding the update service. I have documented my findings at [1]. I think we have everything together to bring a corresponding web service back to life. I think we have at least two options for such a web service. If we want to create a 'real' web service which on demand creates an appropriate response the HTTP GET request contains all needed information in its header fields User-Agent and Accept-Language to implement such a web service. The User-Agent field contains the operating system, the machine architecture and the bundled languages of the installed office. If a corresponding installation package of newer version is available a corresponding response can be generated. Another solution could be to provide a static XML document, based on an atom feed, which contains as much entries as installation packages for the latest version are available. For each installation package which defines itself by the operating system, the machine architecture and the bundled languages an entry is needed. Such entries need to be duplicated for every existing office installation with different UpdateID in its version.ini. Any thoughts, comments, corrections, ...? My opinion: This is an example of a low rate of change application. The data changes every few weeks or months, not daily or hourly. It is also a high traffic service, especially when we have millions of clients doing automatic update checks. So a static file is probably better for server load/performance. I wonder if the static XML file could be automatically generated via a script? Maybe part of our release script? (I assume we'll eventually have a release script that deals with cutting RC's, doing the code signing, etc.) I need to check Oliver's updates to our documentation, but my thought was in agreement with what your propose Rob (if possible) - - at least for the base product, generate the XML nightly(?) for available updates. I hit a wall in many areas, not the least of which is the actual format of the XML feed. Then, we get to deal with fact finding -- what do we have and how do we determine products, buildids, etc. From what I could gather so far, there was some sort of backend product that required manual entry of these kinds of params. Assuming we could actually manually create (now) such and XML feed, at some point we would need to spend time in (perhaps) standardizing on build names etc to do something more or less automatically, and by this I mean, not a web service but just a feed generation. Then, of course there's the extension updatessomewhat the same, somewhat different. BTW, the update service of a certain installed office can be tested locally. No HTTP GET request is involved in this case, but you can test with certain XML documents provided as responses. You can change the value of UpdateURL in file version.ini of your office installation to a local file URL - e.g. under Windows to something like file:///C:/check.update.xml [1] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release -- MzK Follow your bliss. -- attributed to Joseph Campbell
RE: Doctype of websites
Here's my understanding of the situation with regard to DOCTYPE and how pages may be assembled from parts prior to being stored (static) or delivered (dynamic) from the server. If there are any tools that mechanically generate web page body content, partly or in their entirety, you have to ensure that when the final page is served up from the server, the result is compatible with some single DOCTYPE declaration. I assume that the CMS is the likely determining factor, since it will generally be designed to generate a particular grade of HTML. That includes the result following server-side includes as well. There is no reason that national-language choice should be the determining factor. I wonder if that has simply been that the different authoring communities had their own preferences, perhaps related to agreements around authoring tools. Likewise, the character encoding has to be the same throughout the served web page. I presume that is UTF8, since there are NL concerns and it is simply a good choice. That means the httpd setting ensure the proper MIME type with specific character setting is also part of the response header. The only way to be able to operate this in a sane way is to have it be the same for all pages as delivered from the server. There may be similar considerations for the Community Forums and the MediaWiki as well. Those choices can be resolved independently but the DOCTYPE declarations should be accurate at all times, of course. That is not always the case on many sites. - Dennis PS: I'm ignoring the HTML 4.01 vs XHTML 1.0 debate. Going to HTML5 still requires a decision whether it is done using the HTML or XML flavor. No matter what the direction, the problem is going to be how page assembly is done and which page-generating products have to be accommodated. Finally, it is important to have valid pages under whatever the DOCTYPE is and also have a successful result with as many browsers and their users as possible. It might be more valuable to consider what it takes to make the pages adaptable on small-format device browsers (i.e., smartphones and tablets) and pay close attention to accessibility requirements than fuss about not-yet-approved HTML specifications. - Dennis -Original Message- From: Dave Fisher [mailto:dave2w...@comcast.net] Sent: Thursday, March 15, 2012 08:33 To: ooo-dev@incubator.apache.org Subject: Re: Doctype of websites On Mar 15, 2012, at 7:37 AM, Rob Weir wrote: On Thu, Mar 15, 2012 at 10:33 AM, Dave Fisher dave2w...@comcast.net wrote: On Mar 15, 2012, at 12:22 AM, Regina Henschel wrote: Hi, Joe Schaefer schrieb: From: Regina Henschelrb.hensc...@t-online.de To: ooo-dev@incubator.apache.org Sent: Tuesday, March 13, 2012 5:31 PM Subject: Re: Doctype of websites Hi Joe, Joe Schaefer schrieb: Those de.openoffice.org pages should redirect to www.openoffice.org/de pages, if not your DNS resolver is busted. I had indeed set de.openoffice.org to 192.9.163.104. Removing it makes redirecting work. That means the pages at de.openoffice.org had been the original ones, but will be deleted in near future. They had been imported to ooo-site.apache.org/de and here they have got a different doctype. Right? Well sort of. If you look at the actual document on the site you will probably find it contains an XHTML doctype even now. The thing is that the CMS build system as Dave has designed it will strip most of the header matter out of the file and replace it with a generic one supplied by a template. If that's not the problem then you need to refresh your pages as they are identical on the server. As to why the doctype is different from the original document, that's probably due to the way Dave worked out the templates for the site. If we need to scrape the doctype out of each individual page that will require some perl coding work, some templating work, and another sledgehammer style commit- ie not something to be taken lightly. Our pages had been XHTML with all the differences to HTML. And we tried to produce valid pages (including W3C check button). It is not impossible to change the pages and it can be done bit by bit while reviewing the pages. But the aim should be clear. Well I can't advise you how to proceed from here, only point out that there is some impedance mismatch between how your site builds work and what's actually in these documents. The choice seems to be either standardize all the documents on a common doctype or have the perl code pull the doctype out of the original document if it exists and pass it along to the template as an argument. You might even be better off just not supplying a doctype at all and letting the browser figure it out. Up to you folks. If we want valid pages, a common doctype is needed because the inserted part has to be written in a way, that it fits
Re: [MIGRATION] Shut down on remaining Oracle web resources
On Wed, Mar 14, 2012 at 10:20 PM, drew d...@baseanswers.com wrote: On Wed, 2012-03-14 at 21:54 +0100, Roberto Galoppini wrote: On Wed, Mar 14, 2012 at 6:02 AM, Rob Weir robw...@apache.org wrote: On Mon, Mar 12, 2012 at 10:06 PM, Andrew Rist andrew.r...@oracle.com wrote: On 3/12/2012 5:27 PM, Rob Weir wrote: On Wed, Feb 22, 2012 at 12:14 AM, Andrew Ristandrew.r...@oracle.com wrote: I would like to set the date for shutting down these Oracle hosted resources as March 15. (no Shakespeare references, please) This will include mailing lists, mail forwarder, remaining web pages, identity server. What are people's thoughts on this? (sooner is possible, I believe) Hi Andrew, Would it be possible to get one more blast out to the legacy announcement list before we shut it down? Sure - I can do that. If so, I can craft a short note, directing them to the new lists, etc. That would be great. How about something like this: = Subject: Final Reminder on OpenOffice.org mailing list and email forwarder shutdown Please note that the legacy mailing lists for the OpenOfficeOffice.org project will be retired effective March 16h. New mailing lists have been created, at Apache, for users as well as project participants. If you wish to continue to receive occasional email updates from the project, for new releases,etc., then please subscribe to our announcement email list by sending an email to ooo-announce-subscr...@incubator.apache.org. Information on other mailing lists for the project can be found here: http://incubator.apache.org/openofficeorg/mailing-lists.html Also on March 16th we will shutdown the legacy email forwarder for the openoffice.org domain. If you have and use an openoffice.org email address alias, then please note the important information described on the following page: https://blogs.apache.org/OOo/entry/retirement_of_openoffice_org_email Rob, maybe we could update that blog entry adding some info about Extensions/Templates accounts in the Some special instructions for OpenOffice-related services section? Starting from tomorrow Extensions and Templates users authenticating at openoffice.org won't be able to access those systems. As I explained in another thread we need to get some info to recreate those accounts and allow users to change their passwords. Hi Roberto, I just logged onto the extension site and the conversion went as expected. However I'm not able to do the same with the template site, there is an error message: The login is currently not possible: https://www.openoffice.org/api/login - Is this something to be concerned with for today? I'm afraid this is due to openoffice.org login service instability, and actually we (SourceForge) can't do anything about that. Roberto Thanks for all your work on this BTW. //drew We thank you for your past interest and support of the OpenOffice.org project and look forward to your continued support at Apache. Rob Weir, on behalf of the Apache OpenOffice Project Management Committee = If this still makes sense in the morning, we can go with that or something similar. Do you need to send it, or would I send it and then you moderate me in? -Rob A. -Rob Andrew This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you. This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
Re: Doctype of websites
Hi Dennis, On Mar 15, 2012, at 9:58 AM, Dennis E. Hamilton wrote: Here's my understanding of the situation with regard to DOCTYPE and how pages may be assembled from parts prior to being stored (static) or delivered (dynamic) from the server. If there are any tools that mechanically generate web page body content, partly or in their entirety, you have to ensure that when the final page is served up from the server, the result is compatible with some single DOCTYPE declaration. I assume that the CMS is the likely determining factor, since it will generally be designed to generate a particular grade of HTML. That includes the result following server-side includes as well. Yes. The skeleton is in control and what needs adjustment, but it has to interpret many types, some of which use UPPER CASE tags. There is no reason that national-language choice should be the determining factor. I wonder if that has simply been that the different authoring communities had their own preferences, perhaps related to agreements around authoring tools. You don't need to wonder. That is what happened. I particularly like the Mongolian site: http://www.openoffice.org/mn/ The NLC sites are done in many different styles of HTML - there is no general conformance to particular DOCTYPE like there is in say the DE site. Likewise, the character encoding has to be the same throughout the served web page. I presume that is UTF8, since there are NL concerns and it is simply a good choice. That means the httpd setting ensure the proper MIME type with specific character setting is also part of the response header. There are exceptions. Some sites like Sinhalese (http://www.openoffice.org/si/.) do not use UTF-8, but instead use Thai. There are BODY Tags which are a to-do for insertion. Of course, you might want Pastun / Pashto which *is* UTF-8 - http://www.openoffice.org/ps/ There really are a lot of NL sites in various stages. The only way to be able to operate this in a sane way is to have it be the same for all pages as delivered from the server. Most likely it should always be the same. The question is whether conversion to a particular DOCTYPE choice will break parts of the site. In that case we can use the ssi.mdtext trick. NL sites are in the mix because that will be the determining factor. So far the only content area that has a divergent ssi.mdtext is the api. I mention NL because that is where the divergence exists. Have a look you will see great variation. Regards, Dave There may be similar considerations for the Community Forums and the MediaWiki as well. Those choices can be resolved independently but the DOCTYPE declarations should be accurate at all times, of course. That is not always the case on many sites. - Dennis PS: I'm ignoring the HTML 4.01 vs XHTML 1.0 debate. Going to HTML5 still requires a decision whether it is done using the HTML or XML flavor. No matter what the direction, the problem is going to be how page assembly is done and which page-generating products have to be accommodated. Finally, it is important to have valid pages under whatever the DOCTYPE is and also have a successful result with as many browsers and their users as possible. It might be more valuable to consider what it takes to make the pages adaptable on small-format device browsers (i.e., smartphones and tablets) and pay close attention to accessibility requirements than fuss about not-yet-approved HTML specifications. - Dennis -Original Message- From: Dave Fisher [mailto:dave2w...@comcast.net] Sent: Thursday, March 15, 2012 08:33 To: ooo-dev@incubator.apache.org Subject: Re: Doctype of websites On Mar 15, 2012, at 7:37 AM, Rob Weir wrote: On Thu, Mar 15, 2012 at 10:33 AM, Dave Fisher dave2w...@comcast.net wrote: On Mar 15, 2012, at 12:22 AM, Regina Henschel wrote: Hi, Joe Schaefer schrieb: From: Regina Henschelrb.hensc...@t-online.de To: ooo-dev@incubator.apache.org Sent: Tuesday, March 13, 2012 5:31 PM Subject: Re: Doctype of websites Hi Joe, Joe Schaefer schrieb: Those de.openoffice.org pages should redirect to www.openoffice.org/de pages, if not your DNS resolver is busted. I had indeed set de.openoffice.org to 192.9.163.104. Removing it makes redirecting work. That means the pages at de.openoffice.org had been the original ones, but will be deleted in near future. They had been imported to ooo-site.apache.org/de and here they have got a different doctype. Right? Well sort of. If you look at the actual document on the site you will probably find it contains an XHTML doctype even now. The thing is that the CMS build system as Dave has designed it will strip most of the header matter out of the file and replace it with a generic one supplied by a template. If that's not the problem then you need to refresh your pages as
Re: [MIGRATION] Shut down on remaining Oracle web resources
On Wed, Mar 14, 2012 at 12:17 PM, Andrew Rist andrew.r...@oracle.com wrote: On 3/13/2012 10:02 PM, Rob Weir wrote: On Mon, Mar 12, 2012 at 10:06 PM, Andrew Ristandrew.r...@oracle.com wrote: On 3/12/2012 5:27 PM, Rob Weir wrote: On Wed, Feb 22, 2012 at 12:14 AM, Andrew Ristandrew.r...@oracle.com wrote: I would like to set the date for shutting down these Oracle hosted resources as March 15. (no Shakespeare references, please) This will include mailing lists, mail forwarder, remaining web pages, identity server. What are people's thoughts on this? (sooner is possible, I believe) Hi Andrew, Would it be possible to get one more blast out to the legacy announcement list before we shut it down? Sure - I can do that. If so, I can craft a short note, directing them to the new lists, etc. That would be great. How about something like this: = Subject: Final Reminder on OpenOffice.org mailing list and email forwarder shutdown Please note that the legacy mailing lists for the OpenOfficeOffice.org project will be retired effective March 16h. New mailing lists have been created, at Apache, for users as well as project participants. If you wish to continue to receive occasional email updates from the project, for new releases,etc., then please subscribe to our announcement email list by sending an email to ooo-announce-subscr...@incubator.apache.org. Information on other mailing lists for the project can be found here: http://incubator.apache.org/openofficeorg/mailing-lists.html Also on March 16th we will shutdown the legacy email forwarder for the openoffice.org domain. If you have and use an openoffice.org email address alias, then please note the important information described on the following page: https://blogs.apache.org/OOo/entry/retirement_of_openoffice_org_email We thank you for your past interest and support of the OpenOffice.org project and look forward to your continued support at Apache. Rob Weir, on behalf of the Apache OpenOffice Project Management Committee = If this still makes sense in the morning, we can go with that or something similar. Do you need to send it, or would I send it and then you moderate me in? -Rob If you send, I'll moderate through... A. Thanks. It looks like that went out over night. Checking the numbers we got another 2000+ subscribers to the ooo-announce list, which is pretty good since this is the 2nd reminder, and the note was mainly about the email forwarder shutdown and just mentioned the ooo-announce list. -Rob A. -Rob Andrew
Re: [MIGRATION] Shut down on remaining Oracle web resources
On Thu, Mar 15, 2012 at 3:07 PM, Roberto Galoppini rgalopp...@geek.net wrote: On Thu, Mar 15, 2012 at 5:08 PM, Rob Weir robw...@apache.org wrote: On Thu, Mar 15, 2012 at 11:33 AM, Roberto Galoppini rgalopp...@geek.net wrote: On Wed, Mar 14, 2012 at 10:09 PM, Rob Weir robw...@apache.org wrote: snip Sure.. What do you want me to add to that post? Are there some specific instructions? -Rob We might instruct users that to convert their accounts they just need to enter their openoffice.org username and password and ask them to read the messages shown. If they do not remember the password, the link Request new password pages http://extensions.services.openoffice.org/user http://templates.services.openoffice.org/user allows them to receive a link to change e-mail address and password (note that the two websites use different logins). Note that the request new password will work until the @openoffice.org alias will be active. Last but not least, the possibility to use the old password will work until the Oracle authentication server is operational. VERY IMPORTANT: Consider that both kiling the alias forwarding and shutting down the Oracle authentication server will prevent users to login. I hope we can keep alive at least one of those services at least until we'll get from Oracle all necessary information to migrate users. OK. I updated the blog post here: https://blogs.apache.org/OOo/entry/retirement_of_openoffice_org_email But note that there is no guarantee that the announcement list reaches all of those people who have accounts on the extensions or templates website. Is there another list that can be used to contact them? Or is it possible to extract the names of the extension/template owners from the DB and send them an administrative note about the migration? Of course we can do that, but maybe the PPMC doesn't want to send out a message to 40k persons while actually only a tiny fraction of them are or have been active users of the Extensions or Templates website. What do you think? Right. I was hoping there was a way to send an email to only those users who have published an extension or template. -Rob Do you have any metrics on what % of accounts have converted? Extensions: about 12k users, few hundreds have a published content, a dozen or two have converted. Templates: about 28k users, few hundreds have a published content, a dozen or two have converted. Roberto -Rob Roberto This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
Re: [WWW] need a volunteer to update the Native Language main landing page...
On Thu, Mar 15, 2012 at 1:45 PM, Kevin Sisco kevinsisco61...@gmail.comwrote: I would be willing to do it. I have worked with web technologies for some time now and I feel I am verry qualified if you still need someone. Thanks. Kevin-- That would be great. I, personally, have not spent a lot of time analyzing discussions about the N-L former projects in terms of potential new organization, governance etc. If you've done that and feel like taking this on, great! On 3/15/12, Kay Schenk kay.sch...@gmail.com wrote: Hi all-- With Rob's request to add a page about the current NL mailing lists, I took a look at: http://www.openoffice.org/native-lang/ for additional information. Of course, it's not up to date. It would be REALLY great if someone could edit this page/area appropriately given OpenOffice's ASF context. Thanks. -- MzK Follow your bliss. -- attributed to Joseph Campbell -- MzK Follow your bliss. -- attributed to Joseph Campbell
Re: Web page for NL communities ?
On Wed, Mar 14, 2012 at 9:11 AM, Raphael Bircher r.birc...@gmx.ch wrote: Am 14.03.12 17:03, schrieb Kay Schenk: On Wed, Mar 14, 2012 at 6:30 AM, Rob Weir robw...@apache.org wrote: We currently have a web page that lists all of our mailing lists: http://incubator.apache.org/openofficeorg/mailing-lists.html However, the native language lists that we're creating recently are not there. And I think adding them to that page would not be the best approach. I wonder if it would be better to highlight these communities on their own page. So something like this: On our podling page here: http://incubator.apache.org/openofficeorg/ Add new page under Community called Native Language Communities or maybe something a little shorter. This sounds like a lovely idea! On that page, explain a little what these groups are and are not. They are not separate Apache projects, but are interest groups or language sections within the AOO project, concentrating on native language support, localization, marketing efforts, etc. Then have a table listing the languages and the mailing lists. We could also have links to the website, e.g., de.openoffice.org. If there are official social media accounts used by that community (a Facebook page ot Twitter account, for example) we could link to those as well. It might be easiest, considering the state we're in with the NL mailing lists right now, to document these on a wiki page, and just link to THAT from the new NL info page you suggest. But this page is compleetly outdate. If we will link to this page, we have to update this page first. Greetings Raphael yes... -- My private Homepage: http://www.raphaelbircher.ch/ -- MzK Follow your bliss. -- attributed to Joseph Campbell
Re: Feature request: Autofilter blanks nonblanks
oh, also I could make a row for each top 50 and 100 next to it with a check If(blank)... in it and use that in the autofilter... But that's well, ugly... Op 15 maart 2012 23:04 schreef Steven Asselman steven.assel...@gmail.comhet volgende: Hi, I've been trying out OpenOffice today and while I'm very thankful for this good Office, there's a thing that bugs me... The one feature that I find very useful about Excel is the (blanks) and (nonblanks) in the autofilter on a row. Where does this come in use? Well, I have an Excel where I aggregate scores AND ranks in tops for TV-series. From these I calcutate an average of some sorts. The nonblanks come in use when I want to see every tv-serie in a certain top 50. As you can see, this spreadsheet is a mix between a database and a spreadsheet, but... Well, I could write a webapp in C# and access the data from a database... But that's a *huge* workaround. I'm sure I'm not the only one who used Excel like this and it seems to me (blanks)/(nonblanks) seems not to mucht effort to include in an update. Actually, as I'm a software develor myself, I would find this a nice challenge. I hope you can now see why this feature in Excel is helpful. I'm disappointed that this means I still have to use Excel for this sheet, I guess I'm not the only one in the world, so hopefully you know have enough reasons to include this feature-request. Thanks in advance. -- Kind Regards, - Steven Asselman (The Netherlands) -- Met vriendelijke groet, - Steven Asselman
Feature request: Autofilter blanks nonblanks
Hi, I've been trying out OpenOffice today and while I'm very thankful for this good Office, there's a thing that bugs me... The one feature that I find very useful about Excel is the (blanks) and (nonblanks) in the autofilter on a row. Where does this come in use? Well, I have an Excel where I aggregate scores AND ranks in tops for TV-series. From these I calcutate an average of some sorts. The nonblanks come in use when I want to see every tv-serie in a certain top 50. As you can see, this spreadsheet is a mix between a database and a spreadsheet, but... Well, I could write a webapp in C# and access the data from a database... But that's a *huge* workaround. I'm sure I'm not the only one who used Excel like this and it seems to me (blanks)/(nonblanks) seems not to mucht effort to include in an update. Actually, as I'm a software develor myself, I would find this a nice challenge. I hope you can now see why this feature in Excel is helpful. I'm disappointed that this means I still have to use Excel for this sheet, I guess I'm not the only one in the world, so hopefully you know have enough reasons to include this feature-request. Thanks in advance. -- Kind Regards, - Steven Asselman (The Netherlands)
Re: Let's be social
On 03/15/2012 08:03 PM, Rob Weir wrote: We like to say, If it didn't happen on the list, it didn't happen. The idea is that this list (ooo-dev) where project decisions are made, and any discussions among us held elsewhere have no formal status. But that does not mean that we can't share information, informally, via other mechanisms. In fact, I'd encourage us to follow each other and share interesting links and updates with each other. The idea is to supplement the list and use relevant technology appropriately. To get us started, here are my coordinates. If you respond with yours, I'll follow you as well. -Rob Google+: https://plus.google.com/110021943609888508798/ Twitter http://twitter.com/rcweir LinkedIn: http://www.linkedin.com/in/rcweir I think that's a great idea. Google+: https://plus.google.com/u/0/106880516429042964884 Best regards, Carl
Re: Let's be social
Ah Okay, I like where this is going: Live journal http://www.livejournal.com/users/kjsisco I only let people who know me in person follow me on facebook, sorry. On 3/15/12, Rob Weir robw...@apache.org wrote: We like to say, If it didn't happen on the list, it didn't happen. The idea is that this list (ooo-dev) where project decisions are made, and any discussions among us held elsewhere have no formal status. But that does not mean that we can't share information, informally, via other mechanisms. In fact, I'd encourage us to follow each other and share interesting links and updates with each other. The idea is to supplement the list and use relevant technology appropriately. To get us started, here are my coordinates. If you respond with yours, I'll follow you as well. -Rob Google+: https://plus.google.com/110021943609888508798/ Twitter http://twitter.com/rcweir LinkedIn: http://www.linkedin.com/in/rcweir
Re: Feature request: Autofilter blanks nonblanks
Steven, I'm trying to clarify the scenario... Do you mean that, you need a (Blanks)/(Non-Blanks) condition in the autofilter? Why is it related with top 50/100? I just had a quick look. One alternative to do that, is to use Standard Filter...and then set empty/not empty in the filter...not one step solution...does it help? Helen 2012/3/16 Steven Asselman steven.assel...@gmail.com oh, also I could make a row for each top 50 and 100 next to it with a check If(blank)... in it and use that in the autofilter... But that's well, ugly... Op 15 maart 2012 23:04 schreef Steven Asselman steven.assel...@gmail.comhet volgende: Hi, I've been trying out OpenOffice today and while I'm very thankful for this good Office, there's a thing that bugs me... The one feature that I find very useful about Excel is the (blanks) and (nonblanks) in the autofilter on a row. Where does this come in use? Well, I have an Excel where I aggregate scores AND ranks in tops for TV-series. From these I calcutate an average of some sorts. The nonblanks come in use when I want to see every tv-serie in a certain top 50. As you can see, this spreadsheet is a mix between a database and a spreadsheet, but... Well, I could write a webapp in C# and access the data from a database... But that's a *huge* workaround. I'm sure I'm not the only one who used Excel like this and it seems to me (blanks)/(nonblanks) seems not to mucht effort to include in an update. Actually, as I'm a software develor myself, I would find this a nice challenge. I hope you can now see why this feature in Excel is helpful. I'm disappointed that this means I still have to use Excel for this sheet, I guess I'm not the only one in the world, so hopefully you know have enough reasons to include this feature-request. Thanks in advance. -- Kind Regards, - Steven Asselman (The Netherlands) -- Met vriendelijke groet, - Steven Asselman
Re: Let's be social
That sounds nice. ^_*' My G+: https://plus.google.com/106421669546780320263 Twitter: http://twitter.com/imacat_tw Drop me a mail if you would like to add my FB. On 2012/03/16 10:33, Kevin Sisco said: Ah Okay, I like where this is going: Live journal http://www.livejournal.com/users/kjsisco I only let people who know me in person follow me on facebook, sorry. On 3/15/12, Rob Weir robw...@apache.org wrote: We like to say, If it didn't happen on the list, it didn't happen. The idea is that this list (ooo-dev) where project decisions are made, and any discussions among us held elsewhere have no formal status. But that does not mean that we can't share information, informally, via other mechanisms. In fact, I'd encourage us to follow each other and share interesting links and updates with each other. The idea is to supplement the list and use relevant technology appropriately. To get us started, here are my coordinates. If you respond with yours, I'll follow you as well. -Rob Google+: https://plus.google.com/110021943609888508798/ Twitter http://twitter.com/rcweir LinkedIn: http://www.linkedin.com/in/rcweir -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ Apache OpenOffice http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ signature.asc Description: OpenPGP digital signature
