RE: EXTERNAL: Re: Building comphelper

[Steele, Raymond]

Problem after problem.  Now I am getting:

Entering /opt/aoo-4.0.0/main/configmgr/source

Compiling: configmgr/source/partial.cxx
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error: 
Could not find a match for boost::tuples::get(const 
boost::tuples::tuple) needed in 
boost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*, const 
boost::tuples::tuple&).
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: 
Where: While instantiating 
"boost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*, const 
boost::tuples::tuple&)".
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: 
Where: Instantiated from boost::unordered::unordered_map, 
_STL::equal_to, _STL::allocator<_STL::pair>>::operator[](const rtl::OUString&).
"/opt/aoo-4.0.0/main/configmgr/source/partial.cxx", line 82: Where: 
Instantiated from non-template code.
1 Error(s) detected.
dmake:  Error code 2, while making '../unxsoli4.pro/slo/partial.obj'

1 module(s):
configmgr
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making /opt/aoo-4.0.0/main/configmgr/source

When you have fixed the errors in that module you can resume the build by 
running:

build --all:configmgr



I thought I paste it here to see if you could help.  Thanks!

-Original Message-
From: Steele, Raymond 
Sent: Friday, September 06, 2013 3:17 PM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Subject: RE: EXTERNAL: Re: Building comphelper

Herbert, 

To address the isfinite() issue I added the following to rtl/math.hxx:

#ifdef SOLARIS
#undef SAL_MATH_FINITE
#define SAL_MATH_FINITE(d) finite(d)
#endf

Your links were very helpful. Thanks so much. 

Now onto:

integer_fwd.cpp contains the following on line 136 and 137:

136: template < > 137: struct low_bits_mask_t< ::std::numeric_limits::digits>;



-Original Message-
From: Herbert Duerr [mailto:h...@apache.org] 
Sent: Thursday, September 05, 2013 12:34 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper

Hy Raymond,

On 04.09.2013 18:33, Steele, Raymond wrote:
> You are right, I completely missed your post. I am updating my compiler 
> (SolarisStudio 12.3) now.  As far as I can see now, I do not have isfinite is 
> not a member of std on my system. Although, Netbeans allows me to choose C++ 
> Standard C++11. What do you mean by " experiment with the different 
> SAL_MATH_FINITE definitions"?

mathconf.h is a C header file, so we need the C definition of isfinite.

According to [1] the "C" isfinite() should be defined in . Maybe on 
your platform there is a bug similar to [2] that undefines it later. 
But we can assume that isfinite() is available in one form or the other on your 
system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? 
Assuming [3] applies here then finite() may be the pre-standard equivalent to 
the isfinite() function that we are looking for.

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
[3] https://www.varnish-cache.org/trac/ticket/464

What I meant with "experiment with the different SAL_MATH_FINITE definitions" 
is to check whether one of the above pre-standard
isfinite() alternatives work. If you found one then add a define for SOLARIS 
only that doesn't break the other platforms.

By the way std::isfinite() should be provided via  for C++11. But as the 
mathconf.h header is a "C" header this C++11 header is not available in this 
context.

Herbert


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Latest update fucked my spread sheets

[Kay Schenk]

On Thu, Sep 5, 2013 at 3:52 AM, Rob Weir  wrote:

> On Thu, Sep 5, 2013 at 2:16 AM, Oliver-Rainer Wittmann
>  wrote:
> > Hi,
> >
> >
> > On 05.09.2013 02:49, Krynock Construction wrote:
> >>
> >> Just to let you dicks know, I updated the program with the latest
> >> update and all my text documents are fine.  However, ALL my spread
> >> sheets that I use to estimate my jobs, track profit and expenses,
> >> track accounting expenses etc were blown all out of scale and
> >> proportion.  I have to completely redo all my worksheets.  Right when
> >> I have tons of  physical job work, job-related paper work and school
> >> work to get done now I have to redo all of my spreadsheets.  Thanks.
> >> Fuck you, I'm going over to Microsoft Office even if I have to pay.
> >> Better than redoing all my work and then having this shit happen
> >> again.  Can you tell I'm pissed?  I used to love an outside the box
> >> program that was competition to Microsoft. I'm beside myself.
> >
> >
> > Ok.
> >
> > Let us be constructive:
> > If you want to help to get the defect fixed, then please provide a sample
> > spreadsheet document (or more if needed) together with a description of
> want
> > is broken in these spreadsheet documents when using them in AOO 4.0.0.
> >
>
> Are we even aware of any spreadsheet formatting related issues in AOO
> 4.0?  I know of the scrolling/redraw issue.  And the slow save
> performance issue.  But nothing that matches this description: "blown
> all out of scale and proportion".   If this was a common failure we
> would have known about it before a month had past, right?   Any ideas
> what he could be talking about?   One thing we don't know is what
> spreadsheet he had before AOO 4.0.
>
> -Rob
>
>
At the risk of sounding very naive -- could this have anything to do with
font rendering mismatches or even the  little size slider in the lower
right hand corner of Calc. I mention this last item up because I freaked
out one time when I experienced something similar -- I don't recall which
version it was though -- and then, when I figured it out -- it was like "Oh
-- I didn't know that was there!"  Also, I don't really know what the
default setting on that is...

I guess we'll have to wait for image snapshots.


> >
> > Best regards, Oliver.
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

"Truth is stranger than fiction, but it is because Fiction is obliged
 to stick to possibilities. Truth isn't."
 -- "Following the Equator", Mark Twain

RE: EXTERNAL: Re: Building comphelper

[Steele, Raymond]

Herbert, 

To address the isfinite() issue I added the following to rtl/math.hxx:

#ifdef SOLARIS
#undef SAL_MATH_FINITE
#define SAL_MATH_FINITE(d) finite(d)
#endf

Your links were very helpful. Thanks so much. 

Now onto:

integer_fwd.cpp contains the following on line 136 and 137:

136: template < > 137: struct low_bits_mask_t< ::std::numeric_limits::digits>;



-Original Message-
From: Herbert Duerr [mailto:h...@apache.org] 
Sent: Thursday, September 05, 2013 12:34 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper

Hy Raymond,

On 04.09.2013 18:33, Steele, Raymond wrote:
> You are right, I completely missed your post. I am updating my compiler 
> (SolarisStudio 12.3) now.  As far as I can see now, I do not have isfinite is 
> not a member of std on my system. Although, Netbeans allows me to choose C++ 
> Standard C++11. What do you mean by " experiment with the different 
> SAL_MATH_FINITE definitions"?

mathconf.h is a C header file, so we need the C definition of isfinite.

According to [1] the "C" isfinite() should be defined in . Maybe on 
your platform there is a bug similar to [2] that undefines it later. 
But we can assume that isfinite() is available in one form or the other on your 
system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? 
Assuming [3] applies here then finite() may be the pre-standard equivalent to 
the isfinite() function that we are looking for.

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
[3] https://www.varnish-cache.org/trac/ticket/464

What I meant with "experiment with the different SAL_MATH_FINITE definitions" 
is to check whether one of the above pre-standard
isfinite() alternatives work. If you found one then add a define for SOLARIS 
only that doesn't break the other platforms.

By the way std::isfinite() should be provided via  for C++11. But as the 
mathconf.h header is a "C" header this C++11 header is not available in this 
context.

Herbert


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: User questions on dev mailing list

[Kay Schenk]

On Fri, Sep 6, 2013 at 1:37 PM, Andrew Rist  wrote:

>
> On 9/6/2013 4:41 AM, Rob Weir wrote:
> 
>
>  Another angle is to realize that enabling the user and motivating them in
>> a specific direction is more powerful than trying to steer them away from a
>> specific direction. Maybe the problem is we are not making the support
>> forums sound attractive enough? Maybe if we said something like, "For the
>> fastest and most expert response, post your question to"? Make the
>> forums sound like the most attractive option. We know they are the best
>> place for questions, of course. But we ought to describe it equally
>> attractively. -Rob
>>
>
> Perhaps this is a situation of people who are more comfortable with email
> as a tool as opposed to a forum.  If you are not familiar with forums in
> general, our forum can be pretty daunting to navigate - there's a lot of
> info there.
>

I think you could be right about this. The other thing is I think people
want some immediate way, once they get to the contact page, to actually
"DO" something there -- e-mail or a web form -- to get help. So sending
them on to another page is frustrating.

On the "dev" email link being there. I think this is historical from when
we moved the site to Apache and were just getting things started, and maybe
even before we set up us...@openoffice.apache.org. It's placement there now
is not really relevant.

Assuming we put in a link to "users" in the first paragraph, I think the
rest of the e-mail links, with the existing subject lines which are
helpful, should stay.




>
> Do we have a way of bridging the two?  Is there a way to have an email
> address (e.g. forum_questi...@openoffice.org**) that autoposts to a catch
> all forum topic.  Then after the post was triaged, the poster would be
> autosubscribed for replies?
> I have no idea if something like this is possible, but it could provide
> both a bridge to introduce these users to the forum, and a mechanism to
> provide for feedback without having dev become help.
>
> A.
>
>
>
>>>  
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

"Truth is stranger than fiction, but it is because Fiction is obliged
 to stick to possibilities. Truth isn't."
 -- "Following the Equator", Mark Twain

Re: User questions on dev mailing list

[Hagar Delest]

Le 06/09/2013 22:37, Andrew Rist a écrit :

Perhaps this is a situation of people who are more comfortable with email as a 
tool as opposed to a forum.  If you are not familiar with forums in general, 
our forum can be pretty daunting to navigate - there's a lot of info there.

Do we have a way of bridging the two?  Is there a way to have an email address 
(e.g. forum_questi...@openoffice.org) that autoposts to a catch all forum 
topic.  Then after the post was triaged, the poster would be autosubscribed for 
replies?
I have no idea if something like this is possible, but it could provide both a 
bridge to introduce these users to the forum, and a mechanism to provide for 
feedback without having dev become help.


If people are not comfortable with forum then subscribing them automatically is 
not the best method I guess. And anyway, they need to give a password. So I 
don't think we can have a bridge.

Personally, I would change the layout of the mailing list wiki page and put the 
user list in the first place and heavily highlight it, and make clear that the 
other list are very specific.

Hagar

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

permission problem with Windows SDK from snapshot 4.0.1

[Regina Henschel]

Hi,

when I click on Windows version of SDK in 
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds 
I get an error "Forbidden
You don't have permission to access 
/~jsc/developer-snapshots/snapshot/windows/Apache_OpenOffice-SDK_4.0.1_Win_x86_install_en-US.exe 
on this server."


Kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Donation

[Andrea Pescetti]

Bill LLD wrote:

I tried to donate via PayPal. It says there's something wrong with the
recipient's (your) PayPal account.


Thanks for contacting us (and for the intention to donate!). To allow us 
to investigate this, could you provide the address of the page where you 
clicked the Paypal link/button?


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reporting a problem with the OpenOffice website

[Kenneth Aldis]

I downloaded Apache OpenOffice 4.0 on 9-4-13 and got 2 files. I deleted one of 
them and somehow lost both files including in the recycle bin. When I try to 
download again your website won't allow me to do so. My computer is old like me 
and I know I created this problem. Could you please email me a onetime download 
file so I can unpack and install with Windows Explorer. If you can't do this 
then how can you help me download Apache OpenOffice 4.0 from your website. 
Please contact me if you need additional information.
Thank you,
Ken Aldis
k.al...@yahoo.com

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: User questions on dev mailing list

[Andrew Rist]

On 9/6/2013 4:41 AM, Rob Weir wrote:

Another angle is to realize that enabling the user and motivating them 
in a specific direction is more powerful than trying to steer them 
away from a specific direction. Maybe the problem is we are not making 
the support forums sound attractive enough? Maybe if we said something 
like, "For the fastest and most expert response, post your question 
to"? Make the forums sound like the most attractive option. We 
know they are the best place for questions, of course. But we ought to 
describe it equally attractively. -Rob 


Perhaps this is a situation of people who are more comfortable with 
email as a tool as opposed to a forum.  If you are not familiar with 
forums in general, our forum can be pretty daunting to navigate - 
there's a lot of info there.


Do we have a way of bridging the two?  Is there a way to have an email 
address (e.g. forum_questi...@openoffice.org) that autoposts to a catch 
all forum topic.  Then after the post was triaged, the poster would be 
autosubscribed for replies?
I have no idea if something like this is possible, but it could provide 
both a bridge to introduce these users to the forum, and a mechanism to 
provide for feedback without having dev become help.


A.







-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Reporting a problem with the OpenOffice website

[Alexandro Colorado]

Asuming is an english version this is a link:
http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-US/Apache_OpenOffice_4.0.0_Win_x86_install_en-US.exe


On Fri, Sep 6, 2013 at 2:56 PM, Kenneth Aldis  wrote:

> I downloaded Apache OpenOffice 4.0 on 9-4-13 and got 2 files. I deleted
> one of them and somehow lost both files including in the recycle bin. When
> I try to download again your website won't allow me to do so. My computer
> is old like me and I know I created this problem. Could you please email me
> a onetime download file so I can unpack and install with Windows Explorer.
> If you can't do this then how can you help me download Apache OpenOffice
> 4.0 from your website. Please contact me if you need additional information.
> Thank you,
> Ken Aldis
> k.al...@yahoo.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org

Re: requirements for vm-admins of forum/translate/wiki

[Rob Weir]

On Fri, Sep 6, 2013 at 12:14 PM, janI  wrote:
> On 6 September 2013 15:27, Dave Fisher  wrote:
>
>>
>> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
>>
>> > On 9/4/13 10:17 PM, Rob Weir wrote:
>> >> On Wed, Sep 4, 2013 at 12:36 PM, janI  wrote:
>> >>> Hi.
>> >>>
>> >>> We have had some longer discussions on different ML/IRC about how a
>> >>> vm-admin should behave and which level of service we expect for our
>> servers.
>> >>>
>> >>> We need new admins, so this is also a request for anyone interested to
>> chip
>> >>> in.
>> >>>
>> >>> We have had some unfortunate incidents on all 3 vm, of different
>> nature,
>> >>> which made me question if we as a community:
>> >>
>> >> I assume we have vms for Forums and for Wiki.  But what is the 3rd one?
>> >>
>> >>> a) want servers, that are cared for professionally or by happening.
>> >>> b) want to (are capable to) maintain the servers ourself.
>> >>> c) are prepared to support a change that make a), b) possible.
>> >>>
>> >>
>> >> I assume we want well-maintained servers that help us get our
>> >> project-related tasks done, and also help serve our users.
>> >
>> > +1 that is the main goal, a working reliable infra structure that helps
>> > to run our project.
>> >
>> > In the
>> >> past, before you got involved, we were not very "proactive".  It
>> >> seemed like we just waited for something to break, and then tried to
>> >> fix it.
>> >
>> > Exactly and doing it proactive is much better and in the end probably
>> > less work.
>> >
>> >>
>> >> I assume another goal is that we have several people helping with the
>> >> admin, to share the work, avoid burnouts, cover for vacation, etc.
>> >
>> > And that is a very important goal, we need an environment where we can
>> > at any time step in if somebody is not available. I now very well in the
>> > same way as Jan how it is to be a bottleneck. Well it#s true for many
>> > others of us in different areas. But if the servers are not running or
>> > the services not available more people are affected faster
>> >
>> >
>> >>
>> >>> I have formulated some thoughts on how admins could work, but in
>> general I
>> >>> believe we should convince infra to take over the vm responsibility and
>> >>> keep our well functioning forum/wiki admins.
>> >>>
>> >>> We have a vm-team in place, that was created with the purpose of not
>> having
>> >>> a single person as admin. I my opinion the team have not lived up to
>> that
>> >>> purpose but I am still thankful for the help I have received.
>> >>>
>> >>> Remarks the ideas below are my personal thought, which I have used
>> during
>> >>> the time where I maintained the servers:
>> >>>
>> >>> ===
>> >>> The server should at all times be maintained with the following
>> priority:
>> >>> 1) security (the backside of being popular is to have the attention of
>> >>> people who want to gain merit by breaking our servers)
>> >>> 2) stability (we have limited cpu/ram/disk so we must optimize)
>> >>> 3) add user wishes (we already have stable systems, 1,2 are far  more
>> >>> important that enhancing the systems).
>> >>>
>> >>
>> >> and maybe
>> >>
>> >> 3b) Try to evolve systems so users can implement their own wishes, in
>> >> a way compatible with 1) and 2).  For example, if routine logos and
>> >> footers are synched to resources in the project's SVN tree, then any
>> >> committer can update things.
>>
>> I really like this idea.
>>
>
> I am impressed, is this real serious ?
>
> Think about all the fuzz we have had on several MLs because one committer
> successfully convinced a vm-admin to change our logo, and the suggestion is
> to make that automatic.
>
> Any committer who wants a change, just do a "svn commit", is that really
> wanted ?
>

It also makes it possible for any committer to fix a problem if one occurs.

> A couple of questions to that:
>
> Committer X want extension translate, and do a "svn commit" the config is
> updated, but does not work because of other dependencies, who clears up the
> work ? for sure THAT is not a vm-admin task.
>

Same as when a committer checks in code that breaks the build.


> Committer X changes the logo, but doing a "svn commit", Committer Y dont
> like it and does a "svn commit", where are our users in this process or our
> decision process ?
>

Same as when a committer checks in code that someone doesn't like.

We have a community-based process that handles these things already.

Your proposal doesn't really avoid these issues.  It handles it by
having an admin judge the will of the community.

> 3b) is a sure way to scare any prof. SA away, thats pure anarchy.
>

In the good sense of the word "anarchy", yes.

Note:  I wouldn't do this for config files and core system files.  But
why should the logo or banner or footer of the forums or the wiki be
any harder for a committer to edit than the same content of our
website?

Regards,

-Rob


> Dont misunderstand, I have no problem with the community implementing
> something like that, 

RE: EXTERNAL: Re: Building comphelper

[Steele, Raymond]

I am targeting x86. We really need to get this build because of a Java 7 
requirement. I've build some add-ons to AOO version 3.3 that use Java 6, but 
our customer is requiring us to move to Java 7. My  add-ons will not work 
because AOO 3.3 does not recognize the Java 7 JRE.  I reverted back to using 
Solaris 12.3 compilers. Hopefully that reduces your worry about the bridges.  I 
really do appreciate you assistance and hope to overcome this very shortly. 

-Original Message-
From: Steele, Raymond 
Sent: Thursday, September 05, 2013 9:37 AM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Subject: RE: EXTERNAL: Re: Building comphelper

Thanks for the information.  I will give this a try if my current strategy does 
not work. Apparently, SolarisStudios 12.3 compiler is not compatible with 
c++11. I  just finished building GCC 4.8.1 so that  I can attempt to build with 
that.Now, I am  having the issue described here: 
http://wiki.openoffice.org/wiki/OpenSolaris_Build_Instructions/Configure_Errors#Error:_GCC_Linker
 because I have CC and CXX pointing to my new gcc and g++.  How can I  point 
these variables to SolarisStudio compilers for linking, but use gcc for 
compiling?

Raymond

-Original Message-
From: Herbert Duerr [mailto:h...@apache.org] 
Sent: Thursday, September 05, 2013 12:34 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper

Hy Raymond,

On 04.09.2013 18:33, Steele, Raymond wrote:
> You are right, I completely missed your post. I am updating my compiler 
> (SolarisStudio 12.3) now.  As far as I can see now, I do not have isfinite is 
> not a member of std on my system. Although, Netbeans allows me to choose C++ 
> Standard C++11. What do you mean by " experiment with the different 
> SAL_MATH_FINITE definitions"?

mathconf.h is a C header file, so we need the C definition of isfinite.

According to [1] the "C" isfinite() should be defined in . Maybe on 
your platform there is a bug similar to [2] that undefines it later. 
But we can assume that isfinite() is available in one form or the other on your 
system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? 
Assuming [3] applies here then finite() may be the pre-standard equivalent to 
the isfinite() function that we are looking for.

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
[3] https://www.varnish-cache.org/trac/ticket/464

What I meant with "experiment with the different SAL_MATH_FINITE definitions" 
is to check whether one of the above pre-standard
isfinite() alternatives work. If you found one then add a define for SOLARIS 
only that doesn't break the other platforms.

By the way std::isfinite() should be provided via  for C++11. But as the 
mathconf.h header is a "C" header this C++11 header is not available in this 
context.

Herbert


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Has anyone tried AOO with Windows 8.1 Preview?

[Rob Weir]

The ISOs for Win 8.1 are available here:

http://windows.microsoft.com/en-us/windows-8/preview-iso

I'm wondering if anyone has tried AOO 4.0 with it yet?  If there are
any new critical issues there it would be good to know and possibly
fix in 4.0.1.

-Rob

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

[Rob Weir]

On Fri, Sep 6, 2013 at 12:33 PM, janI  wrote:
> On 6 September 2013 16:53, Dick Groskamp  wrote:
>
>> Op 6-9-2013 14:30, janI schreef:
>>
>>  Hi
>>>
>>> I am copying this mail to the l10n list, in order to involve the
>>> translators that do not follow dev@. But lets please keep the discussion
>>> on
>>> dev@.
>>>
>>> As its hopefully known, I have been working on a new workflow for the
>>> whole
>>> translation process for quite a long time.
>>>
>>> Now I have released the first major part of the workflow, my ultimate
>>> commit has lead to some valid concerns from Jürgen and Herbert, this is
>>> the
>>> second time (during development) that I hear the essentially same concern.
>>>
>>> Therefore we a a community need to decide which road we want to follow.
>>>
>>> The workflow I am developing, would in the final phase look like (without
>>> technical details).
>>>
>>> 1) at regular intervals en-US text are extracted from our source tree,
>>> transferred to pootle as templates, and all languages are updates with
>>> new/changed/deleted keys. This part is partly manual (starting the build,
>>> updating the languages).
>>>
>>> 2) Translators work on pootle, Translator-comitters update languages in
>>> svn
>>> from pootle and start an offline language-pack build.
>>>
>>> 3) Translators test their translation using the binary from our buildbot
>>>  +
>>> language pack (translators debug tool). Turnaround time < 1 day.
>>>
>>> 4) Buildbot automatically include changed translations on regular builds
>>> (e.g. weekly).
>>>
>>> The 2 concerns that have been raised are:
>>> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
>>> might produce a build breaker for our buildbots. Suggestion let an admin
>>> do
>>> it e.g. once a week.
>>>
>>> my opinion: We do not need an admin in the loop, we dont have a
>>> controlling
>>> for developers and they are even more likely to produce build breakers.
>>> Remember a .po file build breaker will only affect the language in
>>> question
>>> and can be repaired just as fast.
>>>
>>> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
>>> for en-US developers to download. Suggestion keep the .po file away from
>>> main in extras.
>>>
>>> my opion: Translator work is NOT "extra", its an essential needed part for
>>> our builds. In contrast to e.g. cliparts, the .po are part of the setup
>>> package (of course transformed, similar to a C++ source).
>>>
>>> My workflow can work, not as efficient with 1), but 2) breaks the workflow
>>> for technical reasons (think of someone extracting en-US strings from an
>>> updated /main to an old /extra and the published it to pootle == LOT of
>>> extra translation in all languages.
>>>
>>> I see translators working at the same level as developers, not as
>>> something
>>> /extras, and therefore the work should be treated as such.
>>>
>>> I have stopped work on further integration of genLang, until I either get
>>> lazy consensus on my workflow, or we decide to go for another workflow.
>>>
>>> thanks in advance for your comments (please all on dev@).
>>>
>>> rgds
>>> jan I.
>>>
>>>  In general I have no problem with this workflow and think
>> it might speed up things for the builders side of the proces.
>>
>> The only problem I have is that I'm no techie and SVN is, to be honest,
>> to complicated for me.
>>
>> Would it be possible, for instance after the deadline for translation has
>> passed,
>> for a builder/developer/admin to update ALL languages from POOTLE?
>>
>> I think with something like that we would have have ALL alterations into
>> SVN
>> at once.
>> Mind you I have no idea how much work that would be, but it seems
>> to me it gives some assurance about the imported strings.
>>
>> --
>> DiGro
>> ___
>> Apache OpenOffice 4.0.0 (Dutch) and scanned with Ziggo extended security
>> (F-Secure)
>>
>> thanks for all the comments so far, I am real impressed.
>
> I have to correct/clarify a couple of things.
>
> 1) the build process will not and should not do "svn commit", that are done
> by manually by developers and translator-committers when they feel their
> part is ready (just as developers do).
>
> 2) The emotional part of being in /main or /extra is very important, and
> one I fight for. But equally important it that my workflow will not work
> safely, if it works with 2 svn trees. The chances that someone does a build
> in /main with an not updated /extra (because he/she dont care) is too high,
> and the consequences are down right frightening. If it happes, it might
> change the translation templates, which again changes all language files,
> which ultimately calls for translators to translate false texts. Is that
> really wanted ?
>
> 3) There are absolutely no need to separate at svn/git level, but systems
> have a .ignore facility so directory can be ignored and left empty (which
> would be no problem for my workflow) so any developer not wanting the full
> package, c

4.0.1_release_blocker requested: [Bug 123102] German (de) translation update for OpenOffice 4.0.1

[bugzilla]

Regina Henschel  has asked  for 4.0.1_release_blocker:
Bug 123102: German (de) translation update for OpenOffice 4.0.1
https://issues.apache.org/ooo/show_bug.cgi?id=123102


--- Additional Comments from Regina Henschel 
Hi Jürgen, only to be sure German is integrated.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [CONF] Apache OpenOffice Community > Louis Vuitton Evora 100% Authentic 80% Off Free Shipping

[janI]

On 6 September 2013 18:48, sebb  wrote:

> On 6 September 2013 17:07, Alexandro Colorado  wrote:
> > We are getting some spam attacks on the cWiki, wonder if we can do
> > some scanning to detect similar pages, and also remove this nick.
>
> On the Moin Wikis, anyone can create a Wiki account, but that does not
> grant them write access.
> They then have to apply to the dev list to get added to the
> ContributorsGroup page. [1]
> If anyone abuses their permissions (AFAIK that has not happened) the
> login can easily be removed from the page.
>
> on mwiki its similar and still differerent. You dont need an account to
read, anybody can read without signing in. When they create an account the
get automatic write permission.

I and earlier admins have made 2 suggestions to avoid spam:
1) Write access is not active until x days after creation (typically 4)
2) Write access is not given before approved by an mwiki-admin.

Both suggestions were deemed "negative user experience", so the original
system remains.

jza@: any mwiki admin can block the nich, but you cannot remove a nick that
has made comments/pages.

rgds
jan I.



> [1]
> http://wiki.apache.org/general/OurWikiFarm#per_wiki_access_control_-_tighten_your_wiki_just_a_little.2C_benefit_just_a_lot
> > -- Forwarded message --
> > From: "lily regland (Confluence)" 
> > Date: Fri, 6 Sep 2013 06:08:00 + (UTC)
>
> Please don't forward spam unless it is essential to the reply, and
> then remove as much as possible first.
> Thanks!
>
> 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [CONF] Apache OpenOffice Community > Louis Vuitton Evora 100% Authentic 80% Off Free Shipping

[sebb]

On 6 September 2013 17:07, Alexandro Colorado  wrote:
> We are getting some spam attacks on the cWiki, wonder if we can do
> some scanning to detect similar pages, and also remove this nick.

On the Moin Wikis, anyone can create a Wiki account, but that does not
grant them write access.
They then have to apply to the dev list to get added to the
ContributorsGroup page. [1]
If anyone abuses their permissions (AFAIK that has not happened) the
login can easily be removed from the page.

[1] 
http://wiki.apache.org/general/OurWikiFarm#per_wiki_access_control_-_tighten_your_wiki_just_a_little.2C_benefit_just_a_lot
> -- Forwarded message --
> From: "lily regland (Confluence)" 
> Date: Fri, 6 Sep 2013 06:08:00 + (UTC)

Please don't forward spam unless it is essential to the reply, and
then remove as much as possible first.
Thanks!



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

[Mr. Phan Anh]

What about let the customer choose it from the installation or after
the the installation and integrate a menu command such as "Apply
Vietnamese".
Both of those will need online.
By far, the world is online.
So, keeping this idea will avoid the problem, along with the function
such as "clip art".

On Fri, Sep 6, 2013 at 7:53 PM, Rob Weir  wrote:
> On Fri, Sep 6, 2013 at 8:30 AM, janI  wrote:
>> Hi
>>
>> I am copying this mail to the l10n list, in order to involve the
>> translators that do not follow dev@. But lets please keep the discussion on
>> dev@.
>>
>> As its hopefully known, I have been working on a new workflow for the whole
>> translation process for quite a long time.
>>
>> Now I have released the first major part of the workflow, my ultimate
>> commit has lead to some valid concerns from Jürgen and Herbert, this is the
>> second time (during development) that I hear the essentially same concern.
>>
>> Therefore we a a community need to decide which road we want to follow.
>>
>> The workflow I am developing, would in the final phase look like (without
>> technical details).
>>
>> 1) at regular intervals en-US text are extracted from our source tree,
>> transferred to pootle as templates, and all languages are updates with
>> new/changed/deleted keys. This part is partly manual (starting the build,
>> updating the languages).
>>
>> 2) Translators work on pootle, Translator-comitters update languages in svn
>> from pootle and start an offline language-pack build.
>>
>> 3) Translators test their translation using the binary from our buildbot  +
>> language pack (translators debug tool). Turnaround time < 1 day.
>>
>> 4) Buildbot automatically include changed translations on regular builds
>> (e.g. weekly).
>>
>> The 2 concerns that have been raised are:
>> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
>> might produce a build breaker for our buildbots. Suggestion let an admin do
>> it e.g. once a week.
>>
>> my opinion: We do not need an admin in the loop, we dont have a controlling
>> for developers and they are even more likely to produce build breakers.
>> Remember a .po file build breaker will only affect the language in question
>> and can be repaired just as fast.
>>
>> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
>> for en-US developers to download. Suggestion keep the .po file away from
>> main in extras.
>>
>> my opion: Translator work is NOT "extra", its an essential needed part for
>> our builds. In contrast to e.g. cliparts, the .po are part of the setup
>> package (of course transformed, similar to a C++ source).
>>
>
> I'd plan for growth here.  I see no reason why we will not end up with
> 100+ languages in the future.  Certainly there were that many with
> OpenOffice.org.  So if we have 600Mb for 25 or so languages, will it
> still be a reasonable layout when the languages take up 2.4 GB?
>
> -Rob
>
>
>
>> My workflow can work, not as efficient with 1), but 2) breaks the workflow
>> for technical reasons (think of someone extracting en-US strings from an
>> updated /main to an old /extra and the published it to pootle == LOT of
>> extra translation in all languages.
>>
>> I see translators working at the same level as developers, not as something
>> /extras, and therefore the work should be treated as such.
>>
>> I have stopped work on further integration of genLang, until I either get
>> lazy consensus on my workflow, or we decide to go for another workflow.
>>
>> thanks in advance for your comments (please all on dev@).
>>
>> rgds
>> jan I.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Reporting a problem with the OpenOffice website

[Donald Whytock]

On Fri, Sep 6, 2013 at 1:07 PM, Mr. Phan Anh  wrote:

> Here is the alternative link:
>
> http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-US/Apache_OpenOffice_4.0.0_Win_x86_install_en-US.exe/download
>
> Besides, aware that, the attached elements should be in zip, not by insert
> them inside the email. Your previous email doesnt contain any picture.
>

Plus the mailing list tends to filter attachments.

I believe there's a known issue on the download page where it requires
Javascript to run. I am unable to see the links using my office's IE8,
where some scripting is turned off; however, I can see them in Chrome.

Don

Re: Reporting a problem with the OpenOffice website

[Mr. Phan Anh]

Here is the alternative link:
http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.0/binaries/en-US/Apache_OpenOffice_4.0.0_Win_x86_install_en-US.exe/download

Besides, aware that, the attached elements should be in zip, not by insert
them inside the email. Your previous email doesnt contain any picture.

Re: [CONF] Apache OpenOffice Community > Louis Vuitton Evora 100% Authentic 80% Off Free Shipping

[Alexandro Colorado]

On Fri, Sep 6, 2013 at 12:33 PM, Rob Weir  wrote:

> On Fri, Sep 6, 2013 at 12:54 PM, janI  wrote:
> > On 6 September 2013 18:48, sebb  wrote:
> >
> >> On 6 September 2013 17:07, Alexandro Colorado  wrote:
> >> > We are getting some spam attacks on the cWiki, wonder if we can do
> >> > some scanning to detect similar pages, and also remove this nick.
> >>
> >> On the Moin Wikis, anyone can create a Wiki account, but that does not
> >> grant them write access.
> >> They then have to apply to the dev list to get added to the
> >> ContributorsGroup page. [1]
> >> If anyone abuses their permissions (AFAIK that has not happened) the
> >> login can easily be removed from the page.
> >>
> >> on mwiki its similar and still differerent. You dont need an account to
> > read, anybody can read without signing in. When they create an account
> the
> > get automatic write permission.
> >
>
> Unless I'm missing something it looks like this spam was on the CWiki.
>
> Do we have any options there?
>

​I already remove the page, but I think an admin should be auditing the
last changes on cwiki for the past few days. ​And someone with rights could
either decide to remove or quarentine the user.



>
> -Rob
>
>
>
> > I and earlier admins have made 2 suggestions to avoid spam:
> > 1) Write access is not active until x days after creation (typically 4)
> > 2) Write access is not given before approved by an mwiki-admin.
> >
> > Both suggestions were deemed "negative user experience", so the original
> > system remains.
> >
> > jza@: any mwiki admin can block the nich, but you cannot remove a nick
> that
> > has made comments/pages.
> >
> > rgds
> > jan I.
> >
> >
> >
> >> [1]
> >>
> http://wiki.apache.org/general/OurWikiFarm#per_wiki_access_control_-_tighten_your_wiki_just_a_little.2C_benefit_just_a_lot
> >> > -- Forwarded message --
> >> > From: "lily regland (Confluence)" 
> >> > Date: Fri, 6 Sep 2013 06:08:00 + (UTC)
> >>
> >> Please don't forward spam unless it is essential to the reply, and
> >> then remove as much as possible first.
> >> Thanks!
> >>
> >> 
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org

4.0.1_release_blocker requested: [Bug 123103] Czech (cs) translation update for OpenOffice 4.0.1

[bugzilla]

Andrea Pescetti  has asked  for 4.0.1_release_blocker:
Bug 123103: Czech (cs) translation update for OpenOffice 4.0.1
https://issues.apache.org/ooo/show_bug.cgi?id=123103


--- Additional Comments from Andrea Pescetti 
Czech is updated too for 4.0.1, but it wasn't flagged as release blocker.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: User questions on dev mailing list

[Marcus (OOo)]

Am 09/06/2013 01:41 PM, schrieb Rob Weir:

On Fri, Sep 6, 2013 at 3:39 AM, Marcus (OOo)  wrote:

Am 09/06/2013 03:24 AM, schrieb Dave Fisher:



On Sep 5, 2013, at 4:32 PM, Kay Schenk wrote:


On Thu, Sep 5, 2013 at 4:11 PM, sebb   wrote:


A related issue is: why so many emails with the (irrelevant) subject:

"Reporting a problem with the Open Office website"



that's the pre-constructed subject for the  first entry in:
"If you have technical problems with one of the Apache OpenOffice
websites.."

this was put in a few weeks ago, so folks using this email section would
get more of an indication about what the subject they're sending about.

But we are still getting product problem reports this way. I would still
recommend removing the first reference to contacting the developers,
however.

If folks really do need an immediate e-mail on this Contact Us page, we
could easily put in a mailto: to "us...@openoffice.apache.org" the way
we've done with contact the developers. This would go through moderation,
but at least it would be going to a more appropriate mailing list. Is
this
a good idea?



Yes - and we should shorten the long suggested "subject" with something
like "[Contact]"



I've asked if it's a good idea to extend the subject to see where it comes
from and to show the user (hopefully) "Hey, maybe your text doesn't fit to
the subject, think again". Nobody objected and I did it.

Now it is too long, so I don't understand the objection. Why now?

OK, maybe a little revolution but we should remove any hints to the dev@
list completely as it obviously doesn't work. Just leave some hints to
users@ and the general mailing list webpage.



With a million downloads per week nothing will work perfectly accept
removing any mention of the dev list from that page.

We played with adjusting the wording on the website, and the ordering
of things on the page.  That improved things a little, I think.  But
even a small human error rate multiplied by 65 million will be
significant.

Maybe we shouldn't have a a subject line at all?  That would force the
sender to think and write one.  Many email clients force that.   If we
predefine a subject than many users will just use it unchanged.  This
is OK in some cases, where the intent is clearly expressed by the
subject, like "I am starting the Introduction to Contributing to
Apache OpenOffice" emails.  But it doesn't work well in other cases.


We had no subject line before the change and it was proven not to work. 
And additionally we didn't know where the mails came from.


Now there is a preset subject and - unfortunately - it still doesn't work.

So, going back to not offer a subject line won't change anything to work 
better.



Another angle is to realize that enabling the user and motivating them
in a specific direction is more powerful than trying to steer them
away from a specific direction.  Maybe the problem is we are not
making the support forums sound attractive enough?  Maybe if we said
something like, "For the fastest and most expert response, post your
question to"?  Make the forums sound like the most attractive
option.  We know they are the best place for questions, of course.
But we ought to describe it equally attractively.


Yes, that could maybe work. If someone has ideas to improve the wording 
and to guide the users into the wanted direction, then change, commit 
and wait for the results.


I as non-native speaker think I'm no longer suitable to do these changes.

Marcus




I assume there must be a mailto: link somewhere that is producing this.
The surrounding text may need to be tweaked to reduce these.


On 5 September 2013 22:48, Kay Schenk   wrote:


On Thu, Sep 5, 2013 at 6:29 AM, sebb   wrote:


On 5 September 2013 12:00, Rob Weir   wrote:


On Thu, Sep 5, 2013 at 5:24 AM, sebb   wrote:


The dev list sees the occasional thread which IMO really belongs on
the user list/forum

Although it is convenient for the poster to have the question


answered


on the dev list, I wonder if that is the best approach overall.

The disadvantages of not referring the poster to the user list are


several:



- other users don't benefit from the thread
- the dev list is cluttered with the off-topic threads
- the poster may continue to use the dev list rather than the user
list/forum where there are lots more potential responders

Just a thought.



This is all true.  We also get user questions to the private mailing
list, and via the press alias address.  And we also get product
support questions to the Bugzilla admin alias and the ezmlm admin
alias.

But I don't think we actively encourage users to post questions to do
these things.  But it is a puzzle why this happens.

The main contact page for the project, on the footer of every web
page


is this:



http://www.openoffice.org/contact_us.html

We've adjusted this over time, to make sure that the support options
were first and more prominent.  But we still get misdirected emails,
to the dev, private

Re: [CONF] Apache OpenOffice Community > Louis Vuitton Evora 100% Authentic 80% Off Free Shipping

[Rob Weir]

On Fri, Sep 6, 2013 at 12:54 PM, janI  wrote:
> On 6 September 2013 18:48, sebb  wrote:
>
>> On 6 September 2013 17:07, Alexandro Colorado  wrote:
>> > We are getting some spam attacks on the cWiki, wonder if we can do
>> > some scanning to detect similar pages, and also remove this nick.
>>
>> On the Moin Wikis, anyone can create a Wiki account, but that does not
>> grant them write access.
>> They then have to apply to the dev list to get added to the
>> ContributorsGroup page. [1]
>> If anyone abuses their permissions (AFAIK that has not happened) the
>> login can easily be removed from the page.
>>
>> on mwiki its similar and still differerent. You dont need an account to
> read, anybody can read without signing in. When they create an account the
> get automatic write permission.
>

Unless I'm missing something it looks like this spam was on the CWiki.

Do we have any options there?

-Rob



> I and earlier admins have made 2 suggestions to avoid spam:
> 1) Write access is not active until x days after creation (typically 4)
> 2) Write access is not given before approved by an mwiki-admin.
>
> Both suggestions were deemed "negative user experience", so the original
> system remains.
>
> jza@: any mwiki admin can block the nich, but you cannot remove a nick that
> has made comments/pages.
>
> rgds
> jan I.
>
>
>
>> [1]
>> http://wiki.apache.org/general/OurWikiFarm#per_wiki_access_control_-_tighten_your_wiki_just_a_little.2C_benefit_just_a_lot
>> > -- Forwarded message --
>> > From: "lily regland (Confluence)" 
>> > Date: Fri, 6 Sep 2013 06:08:00 + (UTC)
>>
>> Please don't forward spam unless it is essential to the reply, and
>> then remove as much as possible first.
>> Thanks!
>>
>> 
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Donation

[Bill LLD]

I tried to donate via PayPal. It says there's something wrong with the 
recipient's (your) PayPal account.

Just so you know,
Bill


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [CONF] Apache OpenOffice Community > Louis Vuitton Evora 100% Authentic 80% Off Free Shipping

[janI]

On 6 September 2013 19:00, Alexandro Colorado  wrote:

> On Fri, Sep 6, 2013 at 11:54 AM, janI  wrote:
>
> > On 6 September 2013 18:48, sebb  wrote:
> >
> > > On 6 September 2013 17:07, Alexandro Colorado  wrote:
> > > > We are getting some spam attacks on the cWiki, wonder if we can do
> > > > some scanning to detect similar pages, and also remove this nick.
> > >
> > > On the Moin Wikis, anyone can create a Wiki account, but that does not
> > > grant them write access.
> > > They then have to apply to the dev list to get added to the
> > > ContributorsGroup page. [1]
> > > If anyone abuses their permissions (AFAIK that has not happened) the
> > > login can easily be removed from the page.
> > >
> > > on mwiki its similar and still differerent. You dont need an account to
> > read, anybody can read without signing in. When they create an account
> the
> > get automatic write permission.
> >
> > I and earlier admins have made 2 suggestions to avoid spam:
> > 1) Write access is not active until x days after creation (typically 4)
> > 2) Write access is not given before approved by an mwiki-admin.
> >
> > Both suggestions were deemed "negative user experience", so the original
> > system remains.
> >
>
> When this did change happened? I have experienced this 4 day periods pretty
> often. So this system was set in place until recently. So I am not sure
> when did this got revoked. Also, can't we just get a co-signer system where
> they get instant access as long as someone vows for the user?
>

It was in place when I started looking at mwiki (about 14 months ago), I
have no idea who changed what or why.

The last documented change (before I started) to the configuration was done
by Terry in 2011. Since he works at least as prof. as I do, I am sure all
his changes had PMC backing

A co-signer system is a variant of 2) and was deemed unwanted. Of course
this does not dictate what a future admin implements.

rgds
jan I.




>
>
> >
> > jza@: any mwiki admin can block the nich, but you cannot remove a nick
> > that
> > has made comments/pages.
> >
> > rgds
> > jan I.
> >
> >
> >
> > > [1]
> > >
> >
> http://wiki.apache.org/general/OurWikiFarm#per_wiki_access_control_-_tighten_your_wiki_just_a_little.2C_benefit_just_a_lot
> > > > -- Forwarded message --
> > > > From: "lily regland (Confluence)" 
> > > > Date: Fri, 6 Sep 2013 06:08:00 + (UTC)
> > >
> > > Please don't forward spam unless it is essential to the reply, and
> > > then remove as much as possible first.
> > > Thanks!
> > >
> > > 
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >
> > >
> >
>
>
>
> --
> Alexandro Colorado
> Apache OpenOffice Contributor
> http://www.openoffice.org
>

Re: [CONF] Apache OpenOffice Community > Louis Vuitton Evora 100% Authentic 80% Off Free Shipping

[Alexandro Colorado]

On Fri, Sep 6, 2013 at 11:54 AM, janI  wrote:

> On 6 September 2013 18:48, sebb  wrote:
>
> > On 6 September 2013 17:07, Alexandro Colorado  wrote:
> > > We are getting some spam attacks on the cWiki, wonder if we can do
> > > some scanning to detect similar pages, and also remove this nick.
> >
> > On the Moin Wikis, anyone can create a Wiki account, but that does not
> > grant them write access.
> > They then have to apply to the dev list to get added to the
> > ContributorsGroup page. [1]
> > If anyone abuses their permissions (AFAIK that has not happened) the
> > login can easily be removed from the page.
> >
> > on mwiki its similar and still differerent. You dont need an account to
> read, anybody can read without signing in. When they create an account the
> get automatic write permission.
>
> I and earlier admins have made 2 suggestions to avoid spam:
> 1) Write access is not active until x days after creation (typically 4)
> 2) Write access is not given before approved by an mwiki-admin.
>
> Both suggestions were deemed "negative user experience", so the original
> system remains.
>

When this did change happened? I have experienced this 4 day periods pretty
often. So this system was set in place until recently. So I am not sure
when did this got revoked. Also, can't we just get a co-signer system where
they get instant access as long as someone vows for the user?



>
> jza@: any mwiki admin can block the nich, but you cannot remove a nick
> that
> has made comments/pages.
>
> rgds
> jan I.
>
>
>
> > [1]
> >
> http://wiki.apache.org/general/OurWikiFarm#per_wiki_access_control_-_tighten_your_wiki_just_a_little.2C_benefit_just_a_lot
> > > -- Forwarded message --
> > > From: "lily regland (Confluence)" 
> > > Date: Fri, 6 Sep 2013 06:08:00 + (UTC)
> >
> > Please don't forward spam unless it is essential to the reply, and
> > then remove as much as possible first.
> > Thanks!
> >
> > 
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>



-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org

Re: requirements for vm-admins of forum/translate/wiki

[janI]

On 6 September 2013 15:27, Dave Fisher  wrote:

>
> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
>
> > On 9/4/13 10:17 PM, Rob Weir wrote:
> >> On Wed, Sep 4, 2013 at 12:36 PM, janI  wrote:
> >>> Hi.
> >>>
> >>> We have had some longer discussions on different ML/IRC about how a
> >>> vm-admin should behave and which level of service we expect for our
> servers.
> >>>
> >>> We need new admins, so this is also a request for anyone interested to
> chip
> >>> in.
> >>>
> >>> We have had some unfortunate incidents on all 3 vm, of different
> nature,
> >>> which made me question if we as a community:
> >>
> >> I assume we have vms for Forums and for Wiki.  But what is the 3rd one?
> >>
> >>> a) want servers, that are cared for professionally or by happening.
> >>> b) want to (are capable to) maintain the servers ourself.
> >>> c) are prepared to support a change that make a), b) possible.
> >>>
> >>
> >> I assume we want well-maintained servers that help us get our
> >> project-related tasks done, and also help serve our users.
> >
> > +1 that is the main goal, a working reliable infra structure that helps
> > to run our project.
> >
> > In the
> >> past, before you got involved, we were not very "proactive".  It
> >> seemed like we just waited for something to break, and then tried to
> >> fix it.
> >
> > Exactly and doing it proactive is much better and in the end probably
> > less work.
> >
> >>
> >> I assume another goal is that we have several people helping with the
> >> admin, to share the work, avoid burnouts, cover for vacation, etc.
> >
> > And that is a very important goal, we need an environment where we can
> > at any time step in if somebody is not available. I now very well in the
> > same way as Jan how it is to be a bottleneck. Well it#s true for many
> > others of us in different areas. But if the servers are not running or
> > the services not available more people are affected faster
> >
> >
> >>
> >>> I have formulated some thoughts on how admins could work, but in
> general I
> >>> believe we should convince infra to take over the vm responsibility and
> >>> keep our well functioning forum/wiki admins.
> >>>
> >>> We have a vm-team in place, that was created with the purpose of not
> having
> >>> a single person as admin. I my opinion the team have not lived up to
> that
> >>> purpose but I am still thankful for the help I have received.
> >>>
> >>> Remarks the ideas below are my personal thought, which I have used
> during
> >>> the time where I maintained the servers:
> >>>
> >>> ===
> >>> The server should at all times be maintained with the following
> priority:
> >>> 1) security (the backside of being popular is to have the attention of
> >>> people who want to gain merit by breaking our servers)
> >>> 2) stability (we have limited cpu/ram/disk so we must optimize)
> >>> 3) add user wishes (we already have stable systems, 1,2 are far  more
> >>> important that enhancing the systems).
> >>>
> >>
> >> and maybe
> >>
> >> 3b) Try to evolve systems so users can implement their own wishes, in
> >> a way compatible with 1) and 2).  For example, if routine logos and
> >> footers are synched to resources in the project's SVN tree, then any
> >> committer can update things.
>
> I really like this idea.
>

I am impressed, is this real serious ?

Think about all the fuzz we have had on several MLs because one committer
successfully convinced a vm-admin to change our logo, and the suggestion is
to make that automatic.

Any committer who wants a change, just do a "svn commit", is that really
wanted ?

A couple of questions to that:

Committer X want extension translate, and do a "svn commit" the config is
updated, but does not work because of other dependencies, who clears up the
work ? for sure THAT is not a vm-admin task.

Committer X changes the logo, but doing a "svn commit", Committer Y dont
like it and does a "svn commit", where are our users in this process or our
decision process ?

3b) is a sure way to scare any prof. SA away, thats pure anarchy.

Dont misunderstand, I have no problem with the community implementing
something like that, just dont expect to get stable well maintained servers
! We have a serious problem with the current admins, expanding that to all
committers, that is something that will be in interesting to watch for a
large distance.


> >>
> >>> Being an admin on a vm is a job that does not take soo much time, but
> >>> requires a lot of monitoring and communication (especially with infra).
> >>>
> >>> A good setup would be, 3 types of admin:
> >>> Each server will have an appointed "owner" (anchor-admin)
> >>> A number of persons have full sudo on a server (admin)
> >>> A number of persons can reboot/restart/work on po files (help-admin)
> >>>
> >>> === Anchor-admin responsibilities ===
> >>> Anchor-admin is the "owner" of the vm and the prime contact to infra.
> >>>
> >>> Anchor-admin has the overall responsibility of the vm.
> >>> 1) help when receiving

Re: Question to all developers and translators: How integrated should translation be ?

[janI]

On 6 September 2013 16:53, Dick Groskamp  wrote:

> Op 6-9-2013 14:30, janI schreef:
>
>  Hi
>>
>> I am copying this mail to the l10n list, in order to involve the
>> translators that do not follow dev@. But lets please keep the discussion
>> on
>> dev@.
>>
>> As its hopefully known, I have been working on a new workflow for the
>> whole
>> translation process for quite a long time.
>>
>> Now I have released the first major part of the workflow, my ultimate
>> commit has lead to some valid concerns from Jürgen and Herbert, this is
>> the
>> second time (during development) that I hear the essentially same concern.
>>
>> Therefore we a a community need to decide which road we want to follow.
>>
>> The workflow I am developing, would in the final phase look like (without
>> technical details).
>>
>> 1) at regular intervals en-US text are extracted from our source tree,
>> transferred to pootle as templates, and all languages are updates with
>> new/changed/deleted keys. This part is partly manual (starting the build,
>> updating the languages).
>>
>> 2) Translators work on pootle, Translator-comitters update languages in
>> svn
>> from pootle and start an offline language-pack build.
>>
>> 3) Translators test their translation using the binary from our buildbot
>>  +
>> language pack (translators debug tool). Turnaround time < 1 day.
>>
>> 4) Buildbot automatically include changed translations on regular builds
>> (e.g. weekly).
>>
>> The 2 concerns that have been raised are:
>> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
>> might produce a build breaker for our buildbots. Suggestion let an admin
>> do
>> it e.g. once a week.
>>
>> my opinion: We do not need an admin in the loop, we dont have a
>> controlling
>> for developers and they are even more likely to produce build breakers.
>> Remember a .po file build breaker will only affect the language in
>> question
>> and can be repaired just as fast.
>>
>> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
>> for en-US developers to download. Suggestion keep the .po file away from
>> main in extras.
>>
>> my opion: Translator work is NOT "extra", its an essential needed part for
>> our builds. In contrast to e.g. cliparts, the .po are part of the setup
>> package (of course transformed, similar to a C++ source).
>>
>> My workflow can work, not as efficient with 1), but 2) breaks the workflow
>> for technical reasons (think of someone extracting en-US strings from an
>> updated /main to an old /extra and the published it to pootle == LOT of
>> extra translation in all languages.
>>
>> I see translators working at the same level as developers, not as
>> something
>> /extras, and therefore the work should be treated as such.
>>
>> I have stopped work on further integration of genLang, until I either get
>> lazy consensus on my workflow, or we decide to go for another workflow.
>>
>> thanks in advance for your comments (please all on dev@).
>>
>> rgds
>> jan I.
>>
>>  In general I have no problem with this workflow and think
> it might speed up things for the builders side of the proces.
>
> The only problem I have is that I'm no techie and SVN is, to be honest,
> to complicated for me.
>
> Would it be possible, for instance after the deadline for translation has
> passed,
> for a builder/developer/admin to update ALL languages from POOTLE?
>
> I think with something like that we would have have ALL alterations into
> SVN
> at once.
> Mind you I have no idea how much work that would be, but it seems
> to me it gives some assurance about the imported strings.
>
> --
> DiGro
> ___
> Apache OpenOffice 4.0.0 (Dutch) and scanned with Ziggo extended security
> (F-Secure)
>
> thanks for all the comments so far, I am real impressed.

I have to correct/clarify a couple of things.

1) the build process will not and should not do "svn commit", that are done
by manually by developers and translator-committers when they feel their
part is ready (just as developers do).

2) The emotional part of being in /main or /extra is very important, and
one I fight for. But equally important it that my workflow will not work
safely, if it works with 2 svn trees. The chances that someone does a build
in /main with an not updated /extra (because he/she dont care) is too high,
and the consequences are down right frightening. If it happes, it might
change the translation templates, which again changes all language files,
which ultimately calls for translators to translate false texts. Is that
really wanted ?

3) There are absolutely no need to separate at svn/git level, but systems
have a .ignore facility so directory can be ignored and left empty (which
would be no problem for my workflow) so any developer not wanting the full
package, can still do a "svn co main" and limit to what is wanted. Btw I
dont need MAC development, why do I have to dowload that ?

4) When we walk about making the system modular, and want to s

Re: Question to all developers and translators: How integrated should translation be ?

[Dick Groskamp]

Op 6-9-2013 14:30, janI schreef:

Hi

I am copying this mail to the l10n list, in order to involve the
translators that do not follow dev@. But lets please keep the discussion on
dev@.

As its hopefully known, I have been working on a new workflow for the whole
translation process for quite a long time.

Now I have released the first major part of the workflow, my ultimate
commit has lead to some valid concerns from Jürgen and Herbert, this is the
second time (during development) that I hear the essentially same concern.

Therefore we a a community need to decide which road we want to follow.

The workflow I am developing, would in the final phase look like (without
technical details).

1) at regular intervals en-US text are extracted from our source tree,
transferred to pootle as templates, and all languages are updates with
new/changed/deleted keys. This part is partly manual (starting the build,
updating the languages).

2) Translators work on pootle, Translator-comitters update languages in svn
from pootle and start an offline language-pack build.

3) Translators test their translation using the binary from our buildbot  +
language pack (translators debug tool). Turnaround time < 1 day.

4) Buildbot automatically include changed translations on regular builds
(e.g. weekly).

The 2 concerns that have been raised are:
1) Letting committers do "svn commit" and "svn up" directly in pootle,
might produce a build breaker for our buildbots. Suggestion let an admin do
it e.g. once a week.

my opinion: We do not need an admin in the loop, we dont have a controlling
for developers and they are even more likely to produce build breakers.
Remember a .po file build breaker will only affect the language in question
and can be repaired just as fast.

2) Containing the .po files (translations) inside main/ cost 600Mb extra
for en-US developers to download. Suggestion keep the .po file away from
main in extras.

my opion: Translator work is NOT "extra", its an essential needed part for
our builds. In contrast to e.g. cliparts, the .po are part of the setup
package (of course transformed, similar to a C++ source).

My workflow can work, not as efficient with 1), but 2) breaks the workflow
for technical reasons (think of someone extracting en-US strings from an
updated /main to an old /extra and the published it to pootle == LOT of
extra translation in all languages.

I see translators working at the same level as developers, not as something
/extras, and therefore the work should be treated as such.

I have stopped work on further integration of genLang, until I either get
lazy consensus on my workflow, or we decide to go for another workflow.

thanks in advance for your comments (please all on dev@).

rgds
jan I.


In general I have no problem with this workflow and think
it might speed up things for the builders side of the proces.

The only problem I have is that I'm no techie and SVN is, to be honest,
to complicated for me.

Would it be possible, for instance after the deadline for translation 
has passed,

for a builder/developer/admin to update ALL languages from POOTLE?

I think with something like that we would have have ALL alterations into SVN
at once.
Mind you I have no idea how much work that would be, but it seems
to me it gives some assurance about the imported strings.

--
DiGro
___
Apache OpenOffice 4.0.0 (Dutch) and scanned with Ziggo extended security 
(F-Secure)


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Fwd: [CONF] Apache OpenOffice Community > Louis Vuitton Evora 100% Authentic 80% Off Free Shipping

[Alexandro Colorado]

We are getting some spam attacks on the cWiki, wonder if we can do
some scanning to detect similar pages, and also remove this nick.

-- Forwarded message --
From: "lily regland (Confluence)" 
Date: Fri, 6 Sep 2013 06:08:00 + (UTC)
Subject: [CONF] Apache OpenOffice Community > Louis Vuitton Evora 100%
Authentic 80% Off Free Shipping
To: comm...@openoffice.apache.org

Louis Vuitton Evora 100% Authentic 80% Off Free Shipping
Page added by lily regland

www.authenticlouisvuittonhandbags1.com is an authorized Louis Vuitton
outlet. All the items on this website are 100% authentic, with
authenticity card, date code, dust bag and care booklet. Our members
can access these sales and enjoy savings of up to 80% on the items.
The Louis Vuitton Evora may be one of the brand's most classical
products. This style bag can be suitable for every occasion and every
season. If you're serious about building a collection, or even about
acquiring your very first piece to start one, you need to start with
the classics.

Louis Vuitton Evora GM Damier Azur Canvas N41134
$258.99

Size: 18.9" x 19.7" x 5.5".
-Natural cowhide leather trimmings
-Shiny golden brass hardware
-Hand or shoulder carry with removable; adjustable strap
-Zipped front pocket
-Interior double patch pocket
-Additional large patch pocket
-Soft Microfiber lining.

Louis Vuitton Evora MM Damier Ebene Canvas N41131
$246.99

Size: 17.3" x 17.3" x 3.9".
-Hand or shoulder carry with removable; adjustable strap
-Zipped front pocket
-Interior double patch pocket
-D-ring for keys and accessories
-Soft Microfiber lining.

Frequently asked questions:
1. Are you selling authentic Louis Vuitton?
We are authorized Louis Vuitton outlet seller. All items on our site
are authentic. Every bag will come with an authenticity card, a unique
serial No. inside the bag, a yellow dust bag and a care booklet.

2. How much is the shipping fee?
It is free shipping and it can arrive at your door in 5 to 7 days.
After the shipment, we will email the tracking No. for you to monitor
the package online.

3. Is shopping on your site safe?
This online shop is committed to safeguarding your privacy when making
online purchases. We respect your privacy and will not willingly share
the information you provide us with outside companies or
organizations. Our website maintains the highest levels of security.
Our site uses high-level SSL encryption technology, the most advanced
security software currently available for online transactions.

E-mail: authenticlouisvuitton-out...@hotmail.com American Tel: 323-992-6802

Stop watching space | Change email notification preferences
View Online | Add Comment


-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

AOO Flyer_SME (was : Yet another flyer)

[Drew Jensen]

On Tue, Sep 3, 2013 at 7:38 PM, Drew Jensen wrote:

> Juergen


I started on an SME (which I suppose is Small /Medium Enterprise) piece,
it's not that far along with respect to the Why column - but I did make a
change to the graphical content, based on Juergen's comment regarding
icons. So I'll put this up to google also, it's a throw back again to 2.0
branding, with the new color.

pdf
https://docs.google.com/file/d/0Bx7ZNEXlmR0IWFpNd3dSOTBCN3c
odt
https://docs.google.com/file/d/0Bx7ZNEXlmR0IZklSaHFSTk84Umc
and the updated svg for the wireframe
https://docs.google.com/file/d/0Bx7ZNEXlmR0IMzU0bnotSHFVMzA

Anyway - SME is too broad for my purpose here and I will work tonight to
focus a bit more on:
Clerical staff and part-time elected officials in very small
municipalities, which is the demographic of the room where my friend will
be pitching his services..

As always - I don't own this stuff, feel free to make it better...

//drew

Re: Call for volunteers for AOO 4.0.1 performance test

[Drew Jensen]

Thanks for that.

I've got kind of my own stress test regiment - I grabbed 4.0.1 snapshot day
before yesterday (sorry likely can't get the one Juergen just started
uploading) and I will throw what I have at it this weekend. Will post to
this thread (update the wiki) with information early next week (Monday if I
can).

Thanks again
//drew


On Fri, Sep 6, 2013 at 4:26 AM, Liu Ping  wrote:

> Hi, all:
>
> AOO 4.0.1 will release. Performance plays an important role in software
> quality. Is there any volunteer who want to run performance test?
>
> I've run AOO performance GUI test on my own machines. I've tried on one
> platforms: Windows 7. The test configure is as follows:
>
> Test Environment: CPU:2.6 GHz; Mem: 8GB; OS: Windows7
> Test Build: AOO.4.0.1_r1518667; Baseline AOO4.0_r1503704
> Test Evaluation Method:Automatically run each test case 8 times and compute
> the average value of 5 times (excluding the first round result, the minimum
> and maximum result).
>
> The test scenario include:  Slideshow, new AOO file, load file and save.
>
> Volunteers could run performance test on other platforms.
>
> Please Post PVT Report in Wiki
> http://wiki.openoffice.org/wiki/QA/PVT_Report
>
> All the automation scripts could be downloaded in AOO project. And it is
> not difficult to set the automation environment. You could follow the
> guide:
>
> *[Automation Development Guide]*
> http://wiki.openoffice.org/wiki/QA/test_automation_guide
>
> [how to run PVT]
> http://wiki.openoffice.org/wiki/QA/PVT
>
> Reminder:
> 1.Be sure that we should keep the test configuration  unchanged between
> build to build.
> 2.PVT of AOO consists of two parts: GUI and UNO. PVT GUI Testing (run
> pvt.gui.benchmark)  and PVT UNO Testing (pvt.uno.Conversion)
>
>
> For any questions, be free to contact with me :
>

4.0.1_release_blocker requested: [Bug 123115] Lithuanian (lt) translation update for OpenOffice 4.0.1

[bugzilla]

Andrea Pescetti  has asked  for 4.0.1_release_blocker:
Bug 123115: Lithuanian (lt) translation update for OpenOffice 4.0.1
https://issues.apache.org/ooo/show_bug.cgi?id=123115


--- Additional Comments from Andrea Pescetti 
Lithuanian is a new language for 4.0.1. PO files are available (see issue page)
and the issue was properly listed in the language updates meta-issue, but it
had not been marked as a release blocker.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[request for review] - Solution for regressions 122862, 122870, 122955, 123161 and 123163

[Oliver-Rainer Wittmann]

Hi,

I had worked on a fix to solve some regressions [1][2][3][4][5] 
introduced into Calc in AOO 4.0.0 by changes for issue 12666 [6].
The patch is attached to issue 122862 [1] and I have committed it on 
trunk, rev. 1520602


Probably, the one or the other can try one of the next build bot 
installation sets from trunk and check the fixed issues and issue 12666.


I would like to have the regressions solved for AOO 4.0.1.
If my fix works fine (may be with the one or the other smaller 
correction), we can go for it.
Otherwise, I will revert the changes made for issue 12666 for AOO 4.0.1 
to get the regressions fixed for AOO 4.0.1

Issue 12666 will then be solved for AOO 4.1

Thanks in advance.

[1] https://issues.apache.org/ooo/show_bug.cgi?id=122862
[2] https://issues.apache.org/ooo/show_bug.cgi?id=122870
[3] https://issues.apache.org/ooo/show_bug.cgi?id=122955
[4] https://issues.apache.org/ooo/show_bug.cgi?id=123161
[5] https://issues.apache.org/ooo/show_bug.cgi?id=123163
[6] https://issues.apache.org/ooo/show_bug.cgi?id=12666


Best regards, Oliver.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

[Andre Fischer]

On 06.09.2013 15:20, Herbert Duerr wrote:

On 06.09.2013 15:03, Rob Weir wrote:

So maybe just rename "extras" to something else if it is merely the
word that is offensive.   But although translations are essential to
the project, modularity is also important.  For example, we don't put
the website in /main do we, although that is important to the project?


Yes, "main" should be renamed to "source" or "src" as this name is too 
presumptuous and I understand why not being in main is considered 
discriminatory. Having a dedicated "source" directory would also help 
to give our repository a more common structure for an open source 
project.


In "extras" we could have templates, clip arts, example documents, etc.


Maybe we should rename that, too, maybe to "data".  Contributors who 
create templates or clip arts are important for our community as well.


-Andre



And "l10n" deserves its own directory tree.

Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

[Andre Fischer]

On 06.09.2013 14:30, janI wrote:

Hi

I am copying this mail to the l10n list, in order to involve the
translators that do not follow dev@. But lets please keep the discussion on
dev@.

As its hopefully known, I have been working on a new workflow for the whole
translation process for quite a long time.

Now I have released the first major part of the workflow, my ultimate
commit has lead to some valid concerns from Jürgen and Herbert, this is the
second time (during development) that I hear the essentially same concern.

Therefore we a a community need to decide which road we want to follow.

The workflow I am developing, would in the final phase look like (without
technical details).

1) at regular intervals en-US text are extracted from our source tree,
transferred to pootle as templates, and all languages are updates with
new/changed/deleted keys. This part is partly manual (starting the build,
updating the languages).

2) Translators work on pootle, Translator-comitters update languages in svn
from pootle and start an offline language-pack build.

3) Translators test their translation using the binary from our buildbot  +
language pack (translators debug tool). Turnaround time < 1 day.

4) Buildbot automatically include changed translations on regular builds
(e.g. weekly).

The 2 concerns that have been raised are:
1) Letting committers do "svn commit" and "svn up" directly in pootle,
might produce a build breaker for our buildbots. Suggestion let an admin do
it e.g. once a week.

my opinion: We do not need an admin in the loop, we dont have a controlling
for developers and they are even more likely to produce build breakers.
Remember a .po file build breaker will only affect the language in question
and can be repaired just as fast.


Keeping the admin out of the loop would be good.  But having SVN 
operations during every build would be bad.


If the commits and updates are done only on request by translators then 
that would be fine.  But if the build system does that on every build 
automatically , the overhead might be too large.




2) Containing the .po files (translations) inside main/ cost 600Mb extra
for en-US developers to download. Suggestion keep the .po file away from
main in extras.

my opion: Translator work is NOT "extra", its an essential needed part for
our builds. In contrast to e.g. cliparts, the .po are part of the setup
package (of course transformed, similar to a C++ source).

My workflow can work, not as efficient with 1), but 2) breaks the workflow
for technical reasons (think of someone extracting en-US strings from an
updated /main to an old /extra and the published it to pootle == LOT of
extra translation in all languages.

I see translators working at the same level as developers, not as something
/extras, and therefore the work should be treated as such.


I think we should be a bit more specific here.  I agree that the work of 
translators and of developers is equally important.  But there are 
differences in their work flows that should not be neglected.  I am not 
a translator but I would expect that the majority of the work of 
translators is done in Pootle (online or offline).  Building OpenOffice 
seems more like a last step to verify the translation results.  In 
contrast developers build OpenOffice, or at least parts of it, on a 
regular basis.  Sometimes several times an hour.  That means that any 
slowdowns of the build process affect translators and developers quite 
differently.


I also think that each group does not need to integrate changes of the 
other too frequently.  When I fix a bug that does not affect any strings 
then translators are probably not very interested in it. That works the 
other way around as well.  I do most of my development work with en_US.  
I don't need frequent language updates to debug, fix, and verify bug 
fixes that are not language dependent.


So, keeping the things somewhat separated make sense.  But we should 
find names that do not imply that one part is more important than the other.


Best regards,
Andre




I have stopped work on further integration of genLang, until I either get
lazy consensus on my workflow, or we decide to go for another workflow.

thanks in advance for your comments (please all on dev@).

rgds
jan I.




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: requirements for vm-admins of forum/translate/wiki

[Dave Fisher]

On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:

> On 9/4/13 10:17 PM, Rob Weir wrote:
>> On Wed, Sep 4, 2013 at 12:36 PM, janI  wrote:
>>> Hi.
>>> 
>>> We have had some longer discussions on different ML/IRC about how a
>>> vm-admin should behave and which level of service we expect for our servers.
>>> 
>>> We need new admins, so this is also a request for anyone interested to chip
>>> in.
>>> 
>>> We have had some unfortunate incidents on all 3 vm, of different nature,
>>> which made me question if we as a community:
>> 
>> I assume we have vms for Forums and for Wiki.  But what is the 3rd one?
>> 
>>> a) want servers, that are cared for professionally or by happening.
>>> b) want to (are capable to) maintain the servers ourself.
>>> c) are prepared to support a change that make a), b) possible.
>>> 
>> 
>> I assume we want well-maintained servers that help us get our
>> project-related tasks done, and also help serve our users. 
> 
> +1 that is the main goal, a working reliable infra structure that helps
> to run our project.
> 
> In the
>> past, before you got involved, we were not very "proactive".  It
>> seemed like we just waited for something to break, and then tried to
>> fix it.
> 
> Exactly and doing it proactive is much better and in the end probably
> less work.
> 
>> 
>> I assume another goal is that we have several people helping with the
>> admin, to share the work, avoid burnouts, cover for vacation, etc.
> 
> And that is a very important goal, we need an environment where we can
> at any time step in if somebody is not available. I now very well in the
> same way as Jan how it is to be a bottleneck. Well it#s true for many
> others of us in different areas. But if the servers are not running or
> the services not available more people are affected faster
> 
> 
>> 
>>> I have formulated some thoughts on how admins could work, but in general I
>>> believe we should convince infra to take over the vm responsibility and
>>> keep our well functioning forum/wiki admins.
>>> 
>>> We have a vm-team in place, that was created with the purpose of not having
>>> a single person as admin. I my opinion the team have not lived up to that
>>> purpose but I am still thankful for the help I have received.
>>> 
>>> Remarks the ideas below are my personal thought, which I have used during
>>> the time where I maintained the servers:
>>> 
>>> ===
>>> The server should at all times be maintained with the following priority:
>>> 1) security (the backside of being popular is to have the attention of
>>> people who want to gain merit by breaking our servers)
>>> 2) stability (we have limited cpu/ram/disk so we must optimize)
>>> 3) add user wishes (we already have stable systems, 1,2 are far  more
>>> important that enhancing the systems).
>>> 
>> 
>> and maybe
>> 
>> 3b) Try to evolve systems so users can implement their own wishes, in
>> a way compatible with 1) and 2).  For example, if routine logos and
>> footers are synched to resources in the project's SVN tree, then any
>> committer can update things.

I really like this idea.

>> 
>>> Being an admin on a vm is a job that does not take soo much time, but
>>> requires a lot of monitoring and communication (especially with infra).
>>> 
>>> A good setup would be, 3 types of admin:
>>> Each server will have an appointed "owner" (anchor-admin)
>>> A number of persons have full sudo on a server (admin)
>>> A number of persons can reboot/restart/work on po files (help-admin)
>>> 
>>> === Anchor-admin responsibilities ===
>>> Anchor-admin is the "owner" of the vm and the prime contact to infra.
>>> 
>>> Anchor-admin has the overall responsibility of the vm.
>>> 1) help when receiving alerts
>>> 2) keep informed on available patches, especial security related patches
>>> 3) create/keep a maintenance plan
>>> 4) coordinate changes external to vm (like dns) with infra
>>> 5) participate in infra discussions relevant for the vm (e.g. certificates)
>>> 6) monitor the vm regularly for resource usage
>>> 7) secure that appl changes are implemented with relevant consensus
>>> 8) discuss work with admin, with the goal that they should be able to take
>>> over one day.
>>> 
>>> These activities are expected to take 3-4 hours pr week, more in the
>>> beginning and less later. The hour usage highly depend on the number and
>>> level of admins.
>>> 
>>> === Admin responsibilities ===
>>> Admins help the anchor admin with ongoing maintenance and have full sudo.
>>> 
>>> All changes must be discussed and agreed with the anchor admin, no change
>>> is so important that it cannot wait until discussed !
>>> 
>> 
>> We might also want an admin-...@openoffice.apache.org list and perhaps
>> a private one as well to coordinate.

Perhaps an admin-dev, but a private one is a not a good idea - the team should 
be on the infrastructure list and infra should know what is up.

>> 
>>> Admins are expected to:
>>> 1) help when receiving alerts
>>> 2) stay informed with the vm con

[RELEASE]: new snapshot and final integration of language updates

[Jürgen Schmidt]

Hi,

we are currently uploading a new snapshot build based on the SNAPSHOT
tag revision 1520285 (corresponding rev. on AOO401 branch 1520244).

The upload is ongoing and takes some time. The wiki page reflects the
new build and if a link is not yet working, please try again later.

This snapshot includes additional languages Serbian Cyrillic and
Vietnamese and further lang updates.

Vietnamese is currently not available on Windows due to build problems.
For creating the download package we have to use the unicode version of
nsis which have support for Vietnamese. But there is some more work
necessary and I won't be able investigate in this problem for this
snapshot. Easy and fast switch to the unicode version doesn't work.
Sorry but Vietnamese is on risk.

For details please check
http://people.apache.org/~jsc/developer-snapshots/snapshot/snapshot_rev1520244.htm

Details of the former snapshot can be found under
http://people.apache.org/~jsc/developer-snapshots/snapshot/snapshot_rev1518667.htm


My plan is to finally update the languages on Monday, that means an
indirect extension of the translation deadline until Sunday Sep 7th.

I plan also to integrate further bug fixes until Wednesday 11th.

Please work with the snapshots and report issues asap that we can take
potential problems into account.

With AOO 4.1 we will shift to a beta release cycle but not for the 4.0.1.

Juergen

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

[Herbert Duerr]

On 06.09.2013 15:03, Rob Weir wrote:

So maybe just rename "extras" to something else if it is merely the
word that is offensive.   But although translations are essential to
the project, modularity is also important.  For example, we don't put
the website in /main do we, although that is important to the project?


Yes, "main" should be renamed to "source" or "src" as this name is too 
presumptuous and I understand why not being in main is considered 
discriminatory. Having a dedicated "source" directory would also help to 
give our repository a more common structure for an open source project.


In "extras" we could have templates, clip arts, example documents, etc.

And "l10n" deserves its own directory tree.

Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

[Rob Weir]

On Fri, Sep 6, 2013 at 8:54 AM, Armin Le Grand  wrote:
> I see translators working at the same level as developers, not as something
>>>
>>> /extras, and therefore the work should be treated as such.
>>
>>
>> It is not ;-) My wife is a translator, I can tell you...
>
> Upps... Before anyone may get that wrong - I clearly meant here that I also
> see it as the same and I treat it the same.
>

So maybe just rename "extras" to something else if it is merely the
word that is offensive.   But although translations are essential to
the project, modularity is also important.  For example, we don't put
the website in /main do we, although that is important to the project?

-Rob


> --
> ALG
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

[Rob Weir]

On Fri, Sep 6, 2013 at 8:30 AM, janI  wrote:
> Hi
>
> I am copying this mail to the l10n list, in order to involve the
> translators that do not follow dev@. But lets please keep the discussion on
> dev@.
>
> As its hopefully known, I have been working on a new workflow for the whole
> translation process for quite a long time.
>
> Now I have released the first major part of the workflow, my ultimate
> commit has lead to some valid concerns from Jürgen and Herbert, this is the
> second time (during development) that I hear the essentially same concern.
>
> Therefore we a a community need to decide which road we want to follow.
>
> The workflow I am developing, would in the final phase look like (without
> technical details).
>
> 1) at regular intervals en-US text are extracted from our source tree,
> transferred to pootle as templates, and all languages are updates with
> new/changed/deleted keys. This part is partly manual (starting the build,
> updating the languages).
>
> 2) Translators work on pootle, Translator-comitters update languages in svn
> from pootle and start an offline language-pack build.
>
> 3) Translators test their translation using the binary from our buildbot  +
> language pack (translators debug tool). Turnaround time < 1 day.
>
> 4) Buildbot automatically include changed translations on regular builds
> (e.g. weekly).
>
> The 2 concerns that have been raised are:
> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
> might produce a build breaker for our buildbots. Suggestion let an admin do
> it e.g. once a week.
>
> my opinion: We do not need an admin in the loop, we dont have a controlling
> for developers and they are even more likely to produce build breakers.
> Remember a .po file build breaker will only affect the language in question
> and can be repaired just as fast.
>
> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
> for en-US developers to download. Suggestion keep the .po file away from
> main in extras.
>
> my opion: Translator work is NOT "extra", its an essential needed part for
> our builds. In contrast to e.g. cliparts, the .po are part of the setup
> package (of course transformed, similar to a C++ source).
>

I'd plan for growth here.  I see no reason why we will not end up with
100+ languages in the future.  Certainly there were that many with
OpenOffice.org.  So if we have 600Mb for 25 or so languages, will it
still be a reasonable layout when the languages take up 2.4 GB?

-Rob



> My workflow can work, not as efficient with 1), but 2) breaks the workflow
> for technical reasons (think of someone extracting en-US strings from an
> updated /main to an old /extra and the published it to pootle == LOT of
> extra translation in all languages.
>
> I see translators working at the same level as developers, not as something
> /extras, and therefore the work should be treated as such.
>
> I have stopped work on further integration of genLang, until I either get
> lazy consensus on my workflow, or we decide to go for another workflow.
>
> thanks in advance for your comments (please all on dev@).
>
> rgds
> jan I.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

[Armin Le Grand]

I see translators working at the same level as developers, not as something

/extras, and therefore the work should be treated as such.


It is not ;-) My wife is a translator, I can tell you...
Upps... Before anyone may get that wrong - I clearly meant here that I 
also see it as the same and I treat it the same.

--
ALG

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

[Armin Le Grand]

Hi Jan,

On 06.09.2013 14:30, janI wrote:

Hi

I am copying this mail to the l10n list, in order to involve the
translators that do not follow dev@. But lets please keep the discussion on
dev@.

As its hopefully known, I have been working on a new workflow for the whole
translation process for quite a long time.


Yes, fine thing. Looking forward to it!


Now I have released the first major part of the workflow, my ultimate
commit has lead to some valid concerns from Jürgen and Herbert, this is the
second time (during development) that I hear the essentially same concern.

Therefore we a a community need to decide which road we want to follow.

The workflow I am developing, would in the final phase look like (without
technical details).

1) at regular intervals en-US text are extracted from our source tree,
transferred to pootle as templates, and all languages are updates with
new/changed/deleted keys. This part is partly manual (starting the build,
updating the languages).

2) Translators work on pootle, Translator-comitters update languages in svn
from pootle and start an offline language-pack build.

3) Translators test their translation using the binary from our buildbot  +
language pack (translators debug tool). Turnaround time < 1 day.

4) Buildbot automatically include changed translations on regular builds
(e.g. weekly).

The 2 concerns that have been raised are:
1) Letting committers do "svn commit" and "svn up" directly in pootle,
might produce a build breaker for our buildbots. Suggestion let an admin do
it e.g. once a week.

my opinion: We do not need an admin in the loop, we dont have a controlling
for developers and they are even more likely to produce build breakers.
Remember a .po file build breaker will only affect the language in question
and can be repaired just as fast.


+1, not really avoidable. Producing BuldBreakes is a fast teacher to get 
better/more careful. The alternative is too complicated.



2) Containing the .po files (translations) inside main/ cost 600Mb extra
for en-US developers to download. Suggestion keep the .po file away from
main in extras.

my opion: Translator work is NOT "extra", its an essential needed part for
our builds. In contrast to e.g. cliparts, the .po are part of the setup
package (of course transformed, similar to a C++ source).


Well, the goal is to keep stuff as simple as possible when we want to 
attract new developers. Size of the checkout is one criteria of 
'simple'. The build and stuff to checkout is already too big, reducing 
it would be better than making it bigger.
Plese do not take the name 'extra' wordly, there are many necessary and 
valuable things; take it the other way around: The non-extra should be 
the minimal set to be able to work on the office as a developer.
Thus, I would prefer to keep main small. Maybe a new dir tree besides 
main and extra ('translation', 'languages', ...) would be good and 
self-explanatory.




My workflow can work, not as efficient with 1), but 2) breaks the workflow
for technical reasons (think of someone extracting en-US strings from an
updated /main to an old /extra and the published it to pootle == LOT of
extra translation in all languages.

I see translators working at the same level as developers, not as something
/extras, and therefore the work should be treated as such.


It is not ;-) My wife is a translator, I can tell you...


I have stopped work on further integration of genLang, until I either get
lazy consensus on my workflow, or we decide to go for another workflow.

thanks in advance for your comments (please all on dev@).


If it would not cause too much work to put that 600mb besides main I 
would appreciate it. If it's much extra work, keep it as it is.




rgds
jan I.

Sincerely,
Armin

--
ALG

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Question to all developers and translators: How integrated should translation be ?

[janI]

Hi

I am copying this mail to the l10n list, in order to involve the
translators that do not follow dev@. But lets please keep the discussion on
dev@.

As its hopefully known, I have been working on a new workflow for the whole
translation process for quite a long time.

Now I have released the first major part of the workflow, my ultimate
commit has lead to some valid concerns from Jürgen and Herbert, this is the
second time (during development) that I hear the essentially same concern.

Therefore we a a community need to decide which road we want to follow.

The workflow I am developing, would in the final phase look like (without
technical details).

1) at regular intervals en-US text are extracted from our source tree,
transferred to pootle as templates, and all languages are updates with
new/changed/deleted keys. This part is partly manual (starting the build,
updating the languages).

2) Translators work on pootle, Translator-comitters update languages in svn
from pootle and start an offline language-pack build.

3) Translators test their translation using the binary from our buildbot  +
language pack (translators debug tool). Turnaround time < 1 day.

4) Buildbot automatically include changed translations on regular builds
(e.g. weekly).

The 2 concerns that have been raised are:
1) Letting committers do "svn commit" and "svn up" directly in pootle,
might produce a build breaker for our buildbots. Suggestion let an admin do
it e.g. once a week.

my opinion: We do not need an admin in the loop, we dont have a controlling
for developers and they are even more likely to produce build breakers.
Remember a .po file build breaker will only affect the language in question
and can be repaired just as fast.

2) Containing the .po files (translations) inside main/ cost 600Mb extra
for en-US developers to download. Suggestion keep the .po file away from
main in extras.

my opion: Translator work is NOT "extra", its an essential needed part for
our builds. In contrast to e.g. cliparts, the .po are part of the setup
package (of course transformed, similar to a C++ source).

My workflow can work, not as efficient with 1), but 2) breaks the workflow
for technical reasons (think of someone extracting en-US strings from an
updated /main to an old /extra and the published it to pootle == LOT of
extra translation in all languages.

I see translators working at the same level as developers, not as something
/extras, and therefore the work should be treated as such.

I have stopped work on further integration of genLang, until I either get
lazy consensus on my workflow, or we decide to go for another workflow.

thanks in advance for your comments (please all on dev@).

rgds
jan I.

[QA][Test Report] Weekly Status Update as of 20130906

[Yuzhen Fan]

Hi All,

We continue doing the AOO 4.0.1 showstopper defect verification this week,
here is the weekly update (09/02 - 09/06):

*Test execution*: we run PVT against AOO.4.0.1_r1518667 and compare to the
baseline  AOO4.0_r1503704 (the performance on XLS saving time is improved),
please see detail on separate PVT report
*
Defect summary:*
1. Defect verification(with flag 4.0.0_release_blocker+/?) : there are 27
bugs in backlog now, among of them, 5 are for translation, 8 are for code,
which need actions from native reporters and development, respectively
https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.1_release_blocker%2B%3F&sharer_id=18&list_id=85231

Accomplished this week (only for Function UI)

Verified/FixedReopenedWait for buildLook for env/platform
New fixed/added in backlog
80819

Backlog at end of this week

TotalL10NFunction CodeFunction UI
275814

*Issues & quality highlight:*
1. We cannot contain fixing bugs after Sep 6(the deadline of bugfix),
except defects related to Spreadsheet auto-filter
https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_regression_confirmed&sharer_id=18&list_id=84503
2. The risk on defect verification is catabatic as 5 volunteers join this
work, however, it is sitll tight for more testing around the impact areas
after defect verification

*Volunteer status: *
1. 5 volunteers are on defect verification work for 4.0.1 showstopper
2. No volunteers are for left translation defects' verification
*
Plan for next week:*
1. Work with volunteers to verify showstopper defects (total 27)
2. Play more testing around the impact areas (e.g. Spreadsheet auto-filter)
3. Run GUI PVT against RC build when it is ready (scheduled on 09/14)

Thanks you all for effort this week, we are towards to the release
candidate of AOO 4.0.1, let's continue and make progress next week!

Regards,
Yu Zhen

Re: User questions on dev mailing list

[Rob Weir]

On Fri, Sep 6, 2013 at 3:39 AM, Marcus (OOo)  wrote:
> Am 09/06/2013 03:24 AM, schrieb Dave Fisher:
>
>>
>> On Sep 5, 2013, at 4:32 PM, Kay Schenk wrote:
>>
>>> On Thu, Sep 5, 2013 at 4:11 PM, sebb  wrote:
>>>
 A related issue is: why so many emails with the (irrelevant) subject:

 "Reporting a problem with the Open Office website"

>>>
>>> that's the pre-constructed subject for the  first entry in:
>>> "If you have technical problems with one of the Apache OpenOffice
>>> websites.."
>>>
>>> this was put in a few weeks ago, so folks using this email section would
>>> get more of an indication about what the subject they're sending about.
>>>
>>> But we are still getting product problem reports this way. I would still
>>> recommend removing the first reference to contacting the developers,
>>> however.
>>>
>>> If folks really do need an immediate e-mail on this Contact Us page, we
>>> could easily put in a mailto: to "us...@openoffice.apache.org" the way
>>> we've done with contact the developers. This would go through moderation,
>>> but at least it would be going to a more appropriate mailing list. Is
>>> this
>>> a good idea?
>>
>>
>> Yes - and we should shorten the long suggested "subject" with something
>> like "[Contact]"
>
>
> I've asked if it's a good idea to extend the subject to see where it comes
> from and to show the user (hopefully) "Hey, maybe your text doesn't fit to
> the subject, think again". Nobody objected and I did it.
>
> Now it is too long, so I don't understand the objection. Why now?
>
> OK, maybe a little revolution but we should remove any hints to the dev@
> list completely as it obviously doesn't work. Just leave some hints to
> users@ and the general mailing list webpage.
>

With a million downloads per week nothing will work perfectly accept
removing any mention of the dev list from that page.

We played with adjusting the wording on the website, and the ordering
of things on the page.  That improved things a little, I think.  But
even a small human error rate multiplied by 65 million will be
significant.

Maybe we shouldn't have a a subject line at all?  That would force the
sender to think and write one.  Many email clients force that.   If we
predefine a subject than many users will just use it unchanged.  This
is OK in some cases, where the intent is clearly expressed by the
subject, like "I am starting the Introduction to Contributing to
Apache OpenOffice" emails.  But it doesn't work well in other cases.

Another angle is to realize that enabling the user and motivating them
in a specific direction is more powerful than trying to steer them
away from a specific direction.  Maybe the problem is we are not
making the support forums sound attractive enough?  Maybe if we said
something like, "For the fastest and most expert response, post your
question to"?  Make the forums sound like the most attractive
option.  We know they are the best place for questions, of course.
But we ought to describe it equally attractively.

-Rob


> Marcus
>
>
>
>
 I assume there must be a mailto: link somewhere that is producing this.
 The surrounding text may need to be tweaked to reduce these.


 On 5 September 2013 22:48, Kay Schenk  wrote:
>
> On Thu, Sep 5, 2013 at 6:29 AM, sebb  wrote:
>
>> On 5 September 2013 12:00, Rob Weir  wrote:
>>>
>>> On Thu, Sep 5, 2013 at 5:24 AM, sebb  wrote:

 The dev list sees the occasional thread which IMO really belongs on
 the user list/forum

 Although it is convenient for the poster to have the question

 answered

 on the dev list, I wonder if that is the best approach overall.

 The disadvantages of not referring the poster to the user list are
>>
>> several:


 - other users don't benefit from the thread
 - the dev list is cluttered with the off-topic threads
 - the poster may continue to use the dev list rather than the user
 list/forum where there are lots more potential responders

 Just a thought.

>>>
>>> This is all true.  We also get user questions to the private mailing
>>> list, and via the press alias address.  And we also get product
>>> support questions to the Bugzilla admin alias and the ezmlm admin
>>> alias.
>>>
>>> But I don't think we actively encourage users to post questions to do
>>> these things.  But it is a puzzle why this happens.
>>>
>>> The main contact page for the project, on the footer of every web
>>> page
>>
>> is this:
>>>
>>>
>>> http://www.openoffice.org/contact_us.html
>>>
>>> We've adjusted this over time, to make sure that the support options
>>> were first and more prominent.  But we still get misdirected emails,
>>> to the dev, private, etc. lists.  But with a million downloads a week
>>> there will always be

Re: OptionsPage for my extension

[Rajath Shashidhara]

Hello,

My options page GUI doesn't show up If I include the value of the the
handler in xcu file.
If I make it blank, the GUI is shown. What is the problem with my
OptionsPageHandler?

It works if:
 
doesn't work for this:
 org.apache.aoo.cmisucp.dialog.OptionsPageDialogHandler


On Fri, Sep 6, 2013 at 1:29 PM, Rajath Shashidhara <
rajaths.raja...@gmail.com> wrote:

> Finally found the mistake.
>
> The configuration file entry was missing from the manifest file.
>



-- 
Rajath S,
M.Sc(Hons.) Physics, B.E.(Hons.) Computer Science
Birla Institute of Technology and Science - Pilani,
Pilani

review requested: [Bug 122927] =IF(AK3=" ";0;IF(AK3="Y";195;IF(AK3="N";125))) produces FALSE instead of $0.00 : [Attachment 81470] Fix patch

[bugzilla]

Clarence GUO  has asked  for review:
Bug 122927: =IF(AK3=" ";0;IF(AK3="Y";195;IF(AK3="N";125))) produces FALSE
instead of $0.00
https://issues.apache.org/ooo/show_bug.cgi?id=122927

Attachment 81470: Fix patch
https://issues.apache.org/ooo/attachment.cgi?id=81470&action=edit


--- Additional Comments from Clarence GUO 
In 121126, although in description it only mentioned format code issue,
actually the fix is not only for format code but also for output string for
logic formula cell. The second one introduced this issue.
I think the change for output string change for logic formulas is reasonable
because before 12666, from 12666's sample file, a cell with formula "=2>1" will
return 1.0. It is very strange. It should return "TRUE" like MS Excel.
So my fix will based on 12666.
The root cause is for logic formula cells, fix code of 12666 forcibly set
output string to true or false. But many AOO users had manner already that set
number format to logic formula cells. That's different with Excel. In Excel, no
matter what number format you set to logic formula cells, the output strings
are always true and false. In the sample of this issue, users set number format
to currency, because of the forcibly setting, the string changed.
My solution is to add checking for logic formula cells, if their output number
formats are certain category like number, currency, date, time, etc, we will
not change the output string. but if no certain format categories were applied,
for logic formula cells, will change output string to true and false.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

4.0.1_release_blocker requested: [Bug 123161] In Standard and Advanced Filter "Copy Results to" only works correct for database range as target

[bugzilla]

Oliver-Rainer Wittmann  has asked  for 4.0.1_release_blocker:
Bug 123161: In Standard and Advanced Filter "Copy Results to" only works
correct for database range as target
https://issues.apache.org/ooo/show_bug.cgi?id=123161


--- Additional Comments from Oliver-Rainer Wittmann 
(In reply to burnuser from comment #2)
> Created attachment 81467 [details]
> problemdemo
> 
> Filterresults (List criteria = 3) side by side

Thanks.

My sample and steps overlapped with yours ;-

I am confirming this issue as a regression to AOO 3.4.1

It is caused by the changes for bug 12666 - it belongs to bug 122862, bug
122870, bug 122955 and bug 123163

I am working on a solution, otherwise I will revert changes from bug 12666 for
AOO 4.0.1
--> requesting release blocker flag

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Introduction

[Matt Korman]

Hello,

This is my first time really doing anything like this. My name is Matthew
Korman, a southern New Jersey resident with a BA in journalism, minor in
political science, and roughly four years experience as both a journalist
and editor.

The focus of those four years has been primarily in the entertainment
industry (particularly music), however my most successful position was as a
copy editor from 2009 to 2011. At this point in my career, I know my path
must change for me to become a prominent and successful employee. I can no
longer focus on my absolute passions - music, sports, men's lifestyle
trends, and politics - without admitting to myself that if I haven't gotten
a break yet, that the break probably isn't coming.

This is my chance, I feel, to make a substantial change for good and move
on to a more tangible career - hopefully as some sort of technical writer,
considering my career up to this point has been mostly writing-focuses. I'm
very open to suggestions about what to do moving forward, as I'm more
willing to work than anything else right now.

Thanks again for all of your time.

Sincerely,

Matthew Sean Korman

Reporting a problem with the OpenOffice website

[Edwards, David]

Hi

Just gone to the main download page for Version 4 
(http://www.openoffice.org/download/) and I cannot find the download link. The 
links for downloading Extensions & Templates takes you to a download page but I 
am unable to find the OO4 download.

Here is a screen shot of what I see.

[cid:image001.jpg@01CEAAE7.4C2C6BF0]

Thanks

David Edwards

David Edwards | JACOBS | I.T. Site Operations |Telford | Tel +44 (0)1952 236 
500 |Wolverhampton  Tel +44 (0)1902 428 575 | Mobile +44(0)7535 694528 | 
david.edwa...@jacobs.com | You can also 
contact the IT Helpdesk on 0845 270 0808 or at 
http://helpdesk.jacobs.com
P Please consider the environment before printing this e-mail




NOTICE - This communication may contain confidential and privileged information 
that is for the sole use of the intended recipient. Any viewing, copying or 
distribution of, or reliance on this message by unintended recipients is 
strictly prohibited. If you have received this message in error, please notify 
us immediately by replying to the message and deleting it from your computer.


Jacobs U.K. Limited
1180 Eskdale Road, Winnersh, Wokingham RG41 5TU
Registered in England and Wales under number 2594504

4.0.1_release_blocker granted: [Bug 123201] Asturian (ast) translation update for OpenOffice 4.0.1

[bugzilla]

j...@apache.org has granted Xuacu 's request for
4.0.1_release_blocker:
Bug 123201: Asturian (ast) translation update for OpenOffice 4.0.1
https://issues.apache.org/ooo/show_bug.cgi?id=123201


--- Additional Comments from j...@apache.org
approve showstopper request

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

4.0.1_release_blocker granted: [Bug 122862] Advanced filter uses wrong Data Area

[bugzilla]

j...@apache.org has granted Oliver-Rainer Wittmann 's request
for 4.0.1_release_blocker:
Bug 122862: Advanced filter uses wrong Data Area
https://issues.apache.org/ooo/show_bug.cgi?id=122862


--- Additional Comments from j...@apache.org
approve showstopper request

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

4.0.1_release_blocker granted: [Bug 122870] Advanced filter removes Autofilter

[bugzilla]

j...@apache.org has granted Oliver-Rainer Wittmann 's request
for 4.0.1_release_blocker:
Bug 122870: Advanced filter removes Autofilter
https://issues.apache.org/ooo/show_bug.cgi?id=122870


--- Additional Comments from j...@apache.org
approve showstopper request

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Call for volunteers for AOO 4.0.1 performance test

[Liu Ping]

Hi, all:

AOO 4.0.1 will release. Performance plays an important role in software
quality. Is there any volunteer who want to run performance test?

I've run AOO performance GUI test on my own machines. I've tried on one
platforms: Windows 7. The test configure is as follows:

Test Environment: CPU:2.6 GHz; Mem: 8GB; OS: Windows7
Test Build: AOO.4.0.1_r1518667; Baseline AOO4.0_r1503704
Test Evaluation Method:Automatically run each test case 8 times and compute
the average value of 5 times (excluding the first round result, the minimum
and maximum result).

The test scenario include:  Slideshow, new AOO file, load file and save.

Volunteers could run performance test on other platforms.

Please Post PVT Report in Wiki
http://wiki.openoffice.org/wiki/QA/PVT_Report

All the automation scripts could be downloaded in AOO project. And it is
not difficult to set the automation environment. You could follow the guide:

*[Automation Development Guide]*
http://wiki.openoffice.org/wiki/QA/test_automation_guide

[how to run PVT]
http://wiki.openoffice.org/wiki/QA/PVT

Reminder:
1.Be sure that we should keep the test configuration  unchanged between
build to build.
2.PVT of AOO consists of two parts: GUI and UNO. PVT GUI Testing (run
pvt.gui.benchmark)  and PVT UNO Testing (pvt.uno.Conversion)


For any questions, be free to contact with me :

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

On 05.09.2013 18:37, Steele, Raymond wrote:

Thanks for the information.  I will give this a try if my current strategy does 
not work.

> Apparently, SolarisStudios 12.3 compiler is not compatible with c++11.

We don't build in C++11 mode for (most of) our target platforms yet.


I  just finished building GCC 4.8.1 so that  I can attempt to build with that.


I'm a bit worried about our UNO bridges when I hear this. This code in 
main/bridges/source/cpp_uno is very sensitive to platform/compiler 
changes. GCC 4.8 is quite new and I'm also afraid that the gcc-solaris 
bridges are not as well exercised as their suncc counterparts.


By the way, are you targeting sparc or x86 CPUs?


Now, I am  having the issue described here: 
http://wiki.openoffice.org/wiki/OpenSolaris_Build_Instructions/Configure_Errors#Error:_GCC_Linker
 because I have CC and CXX pointing to my new gcc and g++.  How can I  point 
these variables to SolarisStudio compilers for linking, but use gcc for 
compiling?


If I understand the error message in the referenced Wiki section 
correctly you'd want to link with GNU ld on Solaris if you built with 
gcc and link with Sun ld if you built with Sun CC, so all should be fine 
with CC and CXX being set.


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

4.0.1_release_blocker granted: [Bug 123163] Only one Autofilter per sheet and not any longer per named database range

[bugzilla]

j...@apache.org has granted Oliver-Rainer Wittmann 's request
for 4.0.1_release_blocker:
Bug 123163: Only one Autofilter per sheet and not any longer per named database
range
https://issues.apache.org/ooo/show_bug.cgi?id=123163


--- Additional Comments from j...@apache.org
approve showstopper request

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

4.0.1_release_blocker granted: [Bug 122985] Slow working with photos

[bugzilla]

j...@apache.org has granted Armin Le Grand 's request for
4.0.1_release_blocker:
Bug 122985: Slow working with photos
https://issues.apache.org/ooo/show_bug.cgi?id=122985


--- Additional Comments from j...@apache.org
approve showstopper request

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: OptionsPage for my extension

[Rajath Shashidhara]

Finally found the mistake.

The configuration file entry was missing from the manifest file.

Re: OptionsPage for my extension

[Rajath Shashidhara]

Hello Jurgen,

I am not even receiving the "Options" button on the extension.
How can I debug?

Only If I click that "Options" Button, I'll be able to construct the
EventHandler after which I can debug.
Right?


On Fri, Sep 6, 2013 at 12:06 PM, Rajath Shashidhara <
rajaths.raja...@gmail.com> wrote:

> Hello Tsutomu,
>
> That did not work.
>
> This is my configuration file:
>
> 
>  oor:package="org.openoffice.Office" xmlns:oor="
> http://openoffice.org/2001/registry"; xmlns:xs="
> http://www.w3.org/2001/XMLSchema";>
> 
>  oor:op="fuse">
> 
> CMIS UCP Options
> 
> 
> true
> 
> 
>
> %origin%/../../../../../../dialogs/CMISUCPOptionsPage.xdl
> 
> 
>  oor:op="fuse">
>  oor:name="Id">org.apache.aoo.cmisucp.CMISContentProvider
> CMIS
> UCP Options
>  oor:name="OptionsPage">%origin%/../../../../../../dialogs/CMISUCPOptionsPage.xdl
>  oor:name="EventHandlerService">org.apache.aoo.cmisucp.dialog.OptionsDialogHandler
> 
> 
> 
> 
> 
>
> I have stored this as OptionsDialog.xcu in
> registry/data/org/openoffice/Office.
>
> My Extension identifier is :
> org.apache.aoo.cmisucp.CMISContentProvider
>
>
> On Fri, Sep 6, 2013 at 10:55 AM, Tsutomu Uchino wrote:
>
>> Hello,
>>
>> Id of the Leave of your OptionDialog setting should be the same with your
>> extension identifier.
>>
>> Regards
>>
>>
>> 2013/9/6 Rajath Shashidhara 
>>
>> > Hello,
>> >
>> > I'm not getting the "Options" Button for my extension on the extension
>> > manager.
>> > WHere am I going wrong?
>> >
>> >
>> > --
>> > Rajath S,
>> > M.Sc(Hons.) Physics, B.E.(Hons.) Computer Science
>> > Birla Institute of Technology and Science - Pilani,
>> > Pilani
>> >
>>
>
>
>
> --
> Rajath S,
> M.Sc(Hons.) Physics, B.E.(Hons.) Computer Science
> Birla Institute of Technology and Science - Pilani,
> Pilani
>



-- 
Rajath S,
M.Sc(Hons.) Physics, B.E.(Hons.) Computer Science
Birla Institute of Technology and Science - Pilani,
Pilani

Re: User questions on dev mailing list

[Marcus (OOo)]

Am 09/06/2013 03:24 AM, schrieb Dave Fisher:


On Sep 5, 2013, at 4:32 PM, Kay Schenk wrote:


On Thu, Sep 5, 2013 at 4:11 PM, sebb  wrote:


A related issue is: why so many emails with the (irrelevant) subject:

"Reporting a problem with the Open Office website"



that's the pre-constructed subject for the  first entry in:
"If you have technical problems with one of the Apache OpenOffice
websites.."

this was put in a few weeks ago, so folks using this email section would
get more of an indication about what the subject they're sending about.

But we are still getting product problem reports this way. I would still
recommend removing the first reference to contacting the developers,
however.

If folks really do need an immediate e-mail on this Contact Us page, we
could easily put in a mailto: to "us...@openoffice.apache.org" the way
we've done with contact the developers. This would go through moderation,
but at least it would be going to a more appropriate mailing list. Is this
a good idea?


Yes - and we should shorten the long suggested "subject" with something like 
"[Contact]"


I've asked if it's a good idea to extend the subject to see where it 
comes from and to show the user (hopefully) "Hey, maybe your text 
doesn't fit to the subject, think again". Nobody objected and I did it.


Now it is too long, so I don't understand the objection. Why now?

OK, maybe a little revolution but we should remove any hints to the dev@ 
list completely as it obviously doesn't work. Just leave some hints to 
users@ and the general mailing list webpage.


Marcus




I assume there must be a mailto: link somewhere that is producing this.
The surrounding text may need to be tweaked to reduce these.


On 5 September 2013 22:48, Kay Schenk  wrote:

On Thu, Sep 5, 2013 at 6:29 AM, sebb  wrote:


On 5 September 2013 12:00, Rob Weir  wrote:

On Thu, Sep 5, 2013 at 5:24 AM, sebb  wrote:

The dev list sees the occasional thread which IMO really belongs on
the user list/forum

Although it is convenient for the poster to have the question

answered

on the dev list, I wonder if that is the best approach overall.

The disadvantages of not referring the poster to the user list are

several:


- other users don't benefit from the thread
- the dev list is cluttered with the off-topic threads
- the poster may continue to use the dev list rather than the user
list/forum where there are lots more potential responders

Just a thought.



This is all true.  We also get user questions to the private mailing
list, and via the press alias address.  And we also get product
support questions to the Bugzilla admin alias and the ezmlm admin
alias.

But I don't think we actively encourage users to post questions to do
these things.  But it is a puzzle why this happens.

The main contact page for the project, on the footer of every web page

is this:


http://www.openoffice.org/contact_us.html

We've adjusted this over time, to make sure that the support options
were first and more prominent.  But we still get misdirected emails,
to the dev, private, etc. lists.  But with a million downloads a week
there will always be some small number of users who don't read that
page carefully, or maybe think they will get a faster response if they
send to a different list.


[And they are proved right when their off-topic questions are promptly
answered ...]

The second heading currently says:

"If you want to contact the Apache OpenOffice developer team..."

which may explain some of the misdirected questions.
[Who better to ask than a developer if there is a problem?
Maybe I'll get a faster response?]

I think that section should have some explanation as to when it is
appropriate to contact the team directly.
Possibly move it further down the page as well.



Maybe the "contact the Apache OpenOffice developer team" needs to be
removed from the "Contact Us" page entirely.  Honestly, given the

context,

I'm not sure this belongs here. Maybe delete that section and add a

heading

at the end called Mailing Lists and route them to the project mailing

list

page. That might encourage users to  make a better choice for contacting.





-Rob


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Another test of the download page on Browsershots.com

[Marcus (OOo)]

Am 09/06/2013 03:18 AM, schrieb Rob Weir:

On Thu, Sep 5, 2013 at 4:32 PM, Marcus (OOo)  wrote:

Am 09/05/2013 10:20 PM, schrieb Rob Weir:


On Wed, Sep 4, 2013 at 6:46 PM, Marcus (OOo)   wrote:


Am 09/05/2013 12:20 AM, schrieb Rob Weir:


On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)
wrote:



Am 09/04/2013 10:47 PM, schrieb Rob Weir:


http://browsershots.org/http://www.openoffice.org/download/

I'm not sure anyone else can read that.  It might be tied to a cookie.
 But I ran a test to render the download page on 135 browser/os
combinations.  It returns a PNG screenshot for each rendering.  I
looked for which combinations did not render the green download box.

There were 5 failures.  Two I don't think we care about:

Dillo 3.0.2 / Debian 6.0 (squeeze)

and

Kazehakase 0.5.8 / Debian 6.0 (squeeze)

And 3 that we should care about:

MSIE 5.5 / Windows 2008 R2 (Server)

MSIE 6.0 / Windows 2008 R2 (Server)

MSIE 7.0 / Windows 2008 R2 (Server)





I don't agree here. Why do we have to support stone-old browsers?
Because
they are available on a browser testing website? Come on. ;-)



I'm concerned with the error, since it it impacts the more modern IE 6
and
7.

Looking at visits to our website over the past month I see this many
users:

IE 10 -- 857,499
IE 9 -- 250,591
IE 8 -- 420,215
IE 7 -- 69,914
IE 6 -- 27,172
IE 5.5 -- 69

So we're still getting nearly 100K visits/month from these older IE
versions.




The 69 are not really impressive. But 27,000+ for MSIE 6 is surprising.



http://en.wikipedia.org/wiki/Internet_Explorer_5

It's old, MS is no longer supporting it, so IMHO it's done. Nearly the
same
for 6.0.



Right.  But here is a common scenario.  You need to reinstall Windows
on a machine.  Say it is XP or Vista.  Both are supported today, but
both have older browsers by default.  Of course, the first thing you
do on a new machine is run the Windows Updates.  But in parallel with
that you are downloading other software you need, Acrobat Reader, anti
virus, 7-Zip, Notepad++, etc.,  and Apache OpenOffice.   So you might
end up with IE 8 in the end, after all the patches are applied.  But
you start your work with an earlier version,




I would expect that these people first get the basics up-to-date, then
other
applications.



The IE versions all give the same script error:





However, if all browsers show the same error then a fix could get back
all 3
into life at the same time.



That makes sense.




Yes, let's concentrate on the error.



Line 330, Char 1, Code 0, Expected identifier, string or number

This is an odd place for an error, since that appears to be in the
middle of the commented out block for beta releases.

Any ideas?





Yes, if you search in the "index.html" which indeed doesn't make sense.

When looking into "download.js" then you are in the middle of the
"getFilesize()" function. But I've no idea what the problematic point
could
be there.



I wonder if it could be
http://www.openoffice.org/download/release_matrix.js?  Could it be a
coincidence that that file is exactly 329 lines long and the error is
claimed to be in line 330?  Maybe that unnecessary comma at the end of
line 328 is the issue?




Hm, and what about "languages.js"? It has also a semicolon at the end but
the file has only 108 lines. In the "index.html" it will be imported
before
the "release_matrix.js" (I don't know if this really the case) but there
is
no hint for error.

Anyway, let's try. In the test area:

http://ooo-site.staging.apache.org/download/test/index.html
http://ooo-site.staging.apache.org/download/test/other.html

I've committed the deletion of the characters in both files. I think we
need
to wait another 24h until we are allowed to use Browsershots.org again,
right? - At least this is my experience.



I don't know if that restriction is per client IP address or per host,



It's about the tested website that triggers the limit. It doesn't matter who
or which IP is requesting the test.



but we're blocked either way, because of robots.txt on staging:



OK yes, the staging area.



http://ooo-site.staging.apache.org/robots.txt

But if it is OK to publish those changes we should be able to run
another test now.



Hm, I decided to publish the changes already yesterday. To bad that I've not
changed the links from staged to live, sorry. ;-(

Please try again with the real webpages.



Same errors.

I think it is the trailing comma on the last entry in the array.  I
changed in it download/test/release_matrix.js and will test it again
tomorrow.


Ah, good catch. I've published the website, so you can test with the 
real webpage.


I cross my fingers.

Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: XComponentLoader loadComponentfromURL Readonly

[Jürgen Schmidt]

On 9/5/13 5:37 PM, Rajath Shashidhara wrote:
> Hello Alexandro,
> 
> Here is what happens:
> Document is opened through the "Open" Dialog -> User asked if he wants to
> checkout -> If Yes - > Document is checkedout and displayed in read-write
> mode -> Save from Save dialog -> User checksin -> User is asked if he wants
> to checksout.
> 
> When the user chooses not to checkout(initially), the document is opened in
> readonly mode(the cursor cannot be placed in the document).
> 
> When the user doesn't checkout after checking in, the document is reopened
> in the same frame as readonly. Here, the cursor can be placed in the
> document but changes cannot be saved. (in a sense it is read-only because
> it cannot be saved. But, it creates confusion to the user because the
> cursor can  be placed and edited but save button remains deactivated).

It should be possible to switch the frame in readonly mode, you can do
ti via the UI (left to the PDF button). I don't think you have to reload
the whole document. Just make sure that your internal meta data reflect
the new version etc. But that can be optimized later.

In general I believe the workflow via the normal file dialog is possible
but it seems to be too complicate. But this can be changed later as well.

When I think about a sidebar where we can much better provide checkin
and checkout this will be the way to go for the future.

For using the file dialog I can think about a context menu to checkout a
document. Default is without checkout and readonly. But an open document
can than via sidebar checked out.

Save is somewhat special and I can think of a workflow where I can save
the document locally but all changes will be lost if I don't checkin
finally. If the document frame close or the office close the user will
be asked. But of course this is more work and some further investigation
is necessary to figure out how to do it best.

This is not scope of your project keeping in mind that only 2 weeks are
left. But we have an UCP where we can work with and that we can extend
...

Juergen

> 
> As far as code snippet is concerned:
> it is hard to point give the code as snippet because it is a ucb property.
> 
> I'll give the link to my code:
> https://github.com/rajaths589/CMISContentProvider.git
> 
> Code snipped for loadComponentFromURL:
> 
> XMultiComponentFactory xMCF = m_xContext.getServiceManager();
> Object desktop =
> xMCF.createInstanceWithContext("com.sun.star.frame.Desktop", m_xContext);
> XDesktop xDesktop = UnoRuntime.queryInterface(XDesktop.class,
> desktop);
> XFrame current_frame = xDesktop.getCurrentFrame();
> XComponentLoader xComponentLoader =
> (XComponentLoader)UnoRuntime.queryInterface(XComponentLoader.class,
> desktop);
> try
> {
> PropertyValue pv[] = new PropertyValue[1];
> pv[0] = new PropertyValue();
> pv[0].Name = "ReadOnly";
> pv[0].Value = new Any(Type.BOOLEAN,true);
> pv[0].Handle = -1;
> 
> xComponentLoader.loadComponentFromURL(manager.getCompleteURL(),current_frame.getName(),
> FrameSearchFlag.ALL, pv);
> }
> catch(Exception e)
> {
> log.info("what the hell is this");
> }
> 
> Hope this helps.
> 
> 
> 
> On Thu, Sep 5, 2013 at 8:01 PM, Alexandro Colorado  wrote:
> 
>> Can you provide code snippet to be able to provide more quality answer. Is
>> there any other property value being defined and is that definition passing
>> through without problem.
>>
>> F
>> rom some of my search through the DevGuide, it seems that before Read only
>> was defined through a OpenFlag but that was instead repleaced with the own
>> ReadOnly property for the MediaDescriptor service.
>>
>> http://wiki.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Handling_Documents
>>
>>
>>
>>
>> On Thu, Sep 5, 2013 at 8:57 AM, Rajath Shashidhara <
>> rajaths.raja...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I'm passing a propertyvalue, "readOnly"-true to loadComponentFromURL(),
>> but
>>> the openoffice is still not opening in readonly from.
>>> What are the possible sources of error?
>>>
>>> --
>>> Rajath S,
>>> M.Sc(Hons.) Physics, B.E.(Hons.) Computer Science
>>> Birla Institute of Technology and Science - Pilani,
>>> Pilani
>>>
>>
>>
>>
>> --
>> Alexandro Colorado
>> Apache OpenOffice Contributor
>> http://www.openoffice.org
>>
> 
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org