Re: extensions and translations.
Am 11/01/2012 10:07 PM, schrieb jan iversen: Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files It's indeed important but IMHO this shouldn't be part of the decision to draw the standard as it's about formal and general things. - is of interest to the general public in different countries Absolute. - is willing to let the source be controlled/reviewed by committer. With the possibility to become a committer later-on. - accept a vote by the committers to be accepted If a code grant is necessary depends maybe a bit on the amount of the extension source code. If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. Is swext only for extension around AOO Writer or general? If for Writer then it should be located in a different, own directory within the source code. Please help me out here, I am not sure if that is enough for the apache way. I would suggest to define the standard around some factors. Some thoughts: - What is the benefit for AOO? - Is this helful for the general public or only for specific users? - Does it exchange existing functionality with something own? - What are the usage numbers / review comments look like? - How big is the extension (keep in mind we shouldn't blow-up our software too excessive). - Don't install the extension by default but let the user decide what they want, then make 1-3 wizard pages in the installer only for installing extensions Of course this can only work if the extension developer is willing to come into the AOO project with all the things needed (source grant, signed ICLA, header change, voting for releases, etc.). Marcus On 1 November 2012 21:24, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.dewrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/extensions/http://www.openoffice.org/**extensions/ http://www.**openoffice.org/extensions/http://www.openoffice.org/extensions/ how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right. If I am right that they are not part of the general translation, then is that per design so or should it be different ? Yes, this is by design. Extensions are offered to extent your AOO install at any point of time. These are developed by people that do not have to belong to our project (when we put aside
Re: extensions and translations.
+1 to your ideas, much better formulated than mine. see below for comments. Jan On 2 November 2012 12:09, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 11/01/2012 10:07 PM, schrieb jan iversen: Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files It's indeed important but IMHO this shouldn't be part of the decision to draw the standard as it's about formal and general things. - is of interest to the general public in different countries Absolute. - is willing to let the source be controlled/reviewed by committer. With the possibility to become a committer later-on. - accept a vote by the committers to be accepted If a code grant is necessary depends maybe a bit on the amount of the extension source code. +1, but having the option of a vote is not bad...I did not want to write accept that a committer can veto the change. If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. Is swext only for extension around AOO Writer or general? If for Writer then it should be located in a different, own directory within the source code. At least Wiki publisher attaches only to writer. What do you mean within the source code, is main/swext not within ? Please help me out here, I am not sure if that is enough for the apache way. I would suggest to define the standard around some factors. Some thoughts: - What is the benefit for AOO? This might be a bit problematic, who is to judge it. - Is this helful for the general public or only for specific users? +1 - Does it exchange existing functionality with something own? +1 - What are the usage numbers / review comments look like? If I understand it correct, you see the extension first in the usual extensions place, and then it can grow into AOO ? Would there not be cases, where it was developed directly within AOO. - How big is the extension (keep in mind we shouldn't blow-up our software too excessive). Is that not more a problem of release packaging ? We could put the extensions in an own installation, like language packs. - Don't install the extension by default but let the user decide what they want, then make 1-3 wizard pages in the installer only for installing extensions +1 Of course this can only work if the extension developer is willing to come into the AOO project with all the things needed (source grant, signed ICLA, header change, voting for releases, etc.). +1 that is important, extensions integrated in the source must obey the same rules as all other source code. Marcus On 1 November 2012 21:24, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus
Re: extensions and translations.
On 02.11.2012 12:09, Marcus (OOo) wrote: Am 11/01/2012 10:07 PM, schrieb jan iversen: Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files It's indeed important but IMHO this shouldn't be part of the decision to draw the standard as it's about formal and general things. - is of interest to the general public in different countries Absolute. - is willing to let the source be controlled/reviewed by committer. With the possibility to become a committer later-on. - accept a vote by the committers to be accepted If a code grant is necessary depends maybe a bit on the amount of the extension source code. If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. I think that is up to the author of an extension to put it in the AOO source repository. It is up to the community to decide whether to include it in a release. Is swext only for extension around AOO Writer or general? If for Writer then it should be located in a different, own directory within the source code. Only for Writer. I know of at least three directories for extensions: swext/ sdext/ extensions/ I created sdext myself, back in the days. I think we should join the three directories, with extensions/ being the natural candidate to remain. By the way, there is no either or for extensions regarding their presence in the extension repository or in the SVN repository. Many are present in both. -Andre Please help me out here, I am not sure if that is enough for the apache way. I would suggest to define the standard around some factors. Some thoughts: - What is the benefit for AOO? - Is this helful for the general public or only for specific users? - Does it exchange existing functionality with something own? - What are the usage numbers / review comments look like? - How big is the extension (keep in mind we shouldn't blow-up our software too excessive). - Don't install the extension by default but let the user decide what they want, then make 1-3 wizard pages in the installer only for installing extensions Of course this can only work if the extension developer is willing to come into the AOO project with all the things needed (source grant, signed ICLA, header change, voting for releases, etc.). Marcus On 1 November 2012 21:24, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on
Re: extensions and translations.
Am 11/02/2012 01:00 PM, schrieb jan iversen: +1 to your ideas, much better formulated than mine. see below for comments. Jan On 2 November 2012 12:09, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/01/2012 10:07 PM, schrieb jan iversen: Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files It's indeed important but IMHO this shouldn't be part of the decision to draw the standard as it's about formal and general things. - is of interest to the general public in different countries Absolute. - is willing to let the source be controlled/reviewed by committer. With the possibility to become a committer later-on. - accept a vote by the committers to be accepted If a code grant is necessary depends maybe a bit on the amount of the extension source code. +1, but having the option of a vote is not bad...I did not want to write accept that a committer can veto the change. If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. Is swext only for extension around AOO Writer or general? If for Writer then it should be located in a different, own directory within the source code. At least Wiki publisher attaches only to writer. What do you mean within the source code, is main/swext not within ? It is, but I meant somewhere else in the code structure. Maybe it's good to put all extension into an own structure. But I don't know the build system and talking maybe nuts. ;-) Please help me out here, I am not sure if that is enough for the apache way. I would suggest to define the standard around some factors. Some thoughts: - What is the benefit for AOO? This might be a bit problematic, who is to judge it. The community. When we want some extensions to be put into the AOO installer then we have to decide which ones. Of course this should be done with objective facts and not with thumbs up/down or something else. If it's implementing a beautiful sidepane where some elements like navigator, stylist, etc. can be placed then it would be candidate #1. If it's just adding a menu point to change all TOC items into a clickable link then this is not enough. Just to define 2 extremes. - Is this helful for the general public or only for specific users? +1 - Does it exchange existing functionality with something own? +1 - What are the usage numbers / review comments look like? If I understand it correct, you see the extension first in the usual extensions place, and then it can grow into AOO ? Right. Would there not be cases, where it was developed directly within AOO. Then it would be already within AOO. There are a few exceptions like the MySQL connector which has still a GPL license and therefore has to stay outside. - How big is the extension (keep in mind we shouldn't blow-up our software too excessive). Is that not more a problem of release packaging ? Hm, not really. I assume that the extension will bring in new code and not mostly redundant code. You will come to a point where you cannot get more optimazations without to put too much effort into it. I'm not sure but you should see already a difference in size when comiling AOO with the extisting extensions (like the Wiki publisher) and then without any. We could put the extensions in an own installation, like language packs. Yes, some Best of AOO extensions compilations would be a nice idea. - Don't install the extension by default but let the user decide what they want, then make 1-3 wizard pages in the installer only for installing extensions +1 Of course this can only work if the extension developer is willing to come into the AOO project with all the things needed (source grant, signed ICLA, header change, voting for releases, etc.). +1 that is important, extensions integrated in the source must obey the same rules as all other source code. Thanks for your further comments. When we (all of us) can find some more and come to an agreement, we can setup a definition how to get more extensions into AOO and their developers into our project. Marcus On 1 November 2012 21:24, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the
Re: extensions and translations.
Am 11/02/2012 02:02 PM, schrieb Andre Fischer: On 02.11.2012 12:09, Marcus (OOo) wrote: Am 11/01/2012 10:07 PM, schrieb jan iversen: Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files It's indeed important but IMHO this shouldn't be part of the decision to draw the standard as it's about formal and general things. - is of interest to the general public in different countries Absolute. - is willing to let the source be controlled/reviewed by committer. With the possibility to become a committer later-on. - accept a vote by the committers to be accepted If a code grant is necessary depends maybe a bit on the amount of the extension source code. If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. I think that is up to the author of an extension to put it in the AOO source repository. It is up to the community to decide whether to include it in a release. Is swext only for extension around AOO Writer or general? If for Writer then it should be located in a different, own directory within the source code. Only for Writer. I know of at least three directories for extensions: swext/ sdext/ extensions/ I created sdext myself, back in the days. I think we should join the three directories, with extensions/ being the natural candidate to remain. +1 Then there is only one location where to search for extensions. Should it make more simple in the future, also for new joiners. Marcus By the way, there is no either or for extensions regarding their presence in the extension repository or in the SVN repository. Many are present in both. -Andre Please help me out here, I am not sure if that is enough for the apache way. I would suggest to define the standard around some factors. Some thoughts: - What is the benefit for AOO? - Is this helful for the general public or only for specific users? - Does it exchange existing functionality with something own? - What are the usage numbers / review comments look like? - How big is the extension (keep in mind we shouldn't blow-up our software too excessive). - Don't install the extension by default but let the user decide what they want, then make 1-3 wizard pages in the installer only for installing extensions Of course this can only work if the extension developer is willing to come into the AOO project with all the things needed (source grant, signed ICLA, header change, voting for releases, etc.). Marcus On 1 November 2012 21:24, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions
Re: extensions and translations.
On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/**extensions/http://www.openoffice.org/extensions/how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right. If I am right that they are not part of the general translation, then is that per design so or should it be different ? Yes, this is by design. Extensions are offered to extent your AOO install at any point of time. These are developed by people that do not have to belong to our project (when we put aside some exceptions). They can act independently. And therefore they are allowed to (or have to ;-) ) do all on their own; incl. translation. That applies for all extensions and templates available on: - http://extensions.services.**openoffice.orghttp://extensions.services.openoffice.org - http://templates.services.**openoffice.orghttp://templates.services.openoffice.org I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I can. Don't panic. That's a great goal and everybody is thankful to you for doing this task. Marcus
Re: extensions and translations.
On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. We can have a set of standard extensions. And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/**extensions/http://www.openoffice.org/extensions/how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right. If I am right that they are not part of the general translation, then is that per design so or should it be different ? Yes, this is by design. Extensions are offered to extent your AOO install at any point of time. These are developed by people that do not have to belong to our project (when we put aside some exceptions). They can act independently. And therefore they are allowed to (or have to ;-) ) do all on their own; incl. translation. That applies for all extensions and templates available on: - http://extensions.services.**openoffice.orghttp://extensions.services.openoffice.org - http://templates.services.**openoffice.orghttp://templates.services.openoffice.org I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I can. Don't panic. That's a great goal and everybody is thankful to you for doing this task. Marcus
Re: extensions and translations.
On Thu, Nov 1, 2012 at 1:17 PM, Rob Weir robw...@apache.org wrote: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. We can have a set of standard extensions. Agree 100%. Roberto And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/**extensions/ http://www.openoffice.org/extensions/how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right. If I am right that they are not part of the general translation, then is that per design so or should it be different ? Yes, this is by design. Extensions are offered to extent your AOO install at any point of time. These are developed by people that do not have to belong to our project (when we put aside some exceptions). They can act independently. And therefore they are allowed to (or have to ;-) ) do all on their own; incl. translation. That applies for all extensions and templates available on: - http://extensions.services.**openoffice.org http://extensions.services.openoffice.org - http://templates.services.**openoffice.org http://templates.services.openoffice.org I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I can. Don't panic. That's a great goal and everybody is thankful to you for doing this task. Marcus -- This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
Re: extensions and translations.
Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/**extensions/http://www.openoffice.org/extensions/how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right. If I am right that they are not part of the general translation, then is that per design so or should it be different ? Yes, this is by design. Extensions are offered to extent your AOO install at any point of time. These are developed by people that do not have to belong to our project (when we put aside some exceptions). They can act independently. And therefore they are allowed to (or have to ;-) ) do all on their own; incl. translation. That applies for all extensions and templates available on: - http://extensions.services.**openoffice.orghttp://extensions.services.openoffice.org - http://templates.services.**openoffice.orghttp://templates.services.openoffice.org I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I can. Don't panic. That's a great goal and everybody is thankful to you for doing this task. Marcus
Re: extensions and translations.
Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files - is of interest to the general public in different countries - is willing to let the source be controlled/reviewed by committer. - accept a vote by the committers to be accepted If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. Please help me out here, I am not sure if that is enough for the apache way. Jan. On 1 November 2012 21:24, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/extensions/http://www.openoffice.org/**extensions/ http://www.**openoffice.org/extensions/http://www.openoffice.org/extensions/ how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right. If I am right that they are not part of the general translation, then is that per design so or should it be different ? Yes, this is by design. Extensions are offered to extent your AOO install at any point of time. These are developed by people that do not have to belong to our project (when we put aside some exceptions). They can act independently. And therefore they are allowed to (or have to ;-) ) do all on their own; incl. translation. That applies for all extensions and templates available on: - http://extensions.services.**o**penoffice.org http://openoffice.org http://**extensions.services.**openoffice.orghttp://extensions.services.openoffice.org - http://templates.services.**op**enoffice.org http://openoffice.org http://templates.**services.openoffice.orghttp://templates.services.openoffice.org I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I can. Don't panic. That's a great goal and everybody is thankful to you for doing this task. Marcus
Re: extensions and translations.
On Thu, Nov 1, 2012 at 5:07 PM, jan iversen jancasacon...@gmail.com wrote: Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files - is of interest to the general public in different countries - is willing to let the source be controlled/reviewed by committer. - accept a vote by the committers to be accepted If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. Please help me out here, I am not sure if that is enough for the apache way. There are probably two degrees of standard or official extensions. 1) An extension that is released with our binaries, e.g., it is available out-of-the-box, either automatically installed, or available as an option in the installer. 2) An extension that is developed and released by the project, and published in the extension repository. The process for these would be nearly identical, differing only on whether it is released standalone or bundled with the full AOO installer. -Rob Jan. On 1 November 2012 21:24, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/extensions/http://www.openoffice.org/**extensions/ http://www.**openoffice.org/extensions/http://www.openoffice.org/extensions/ how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right. If I am right that they are not part of the general translation, then is that per design so or should it be different ? Yes, this is by design. Extensions are offered to extent your AOO install at any point of time. These are developed by people that do not have to belong to our project (when we put aside some exceptions). They can act independently. And therefore they are allowed to (or have to ;-) ) do all on their own; incl. translation. That applies for all extensions and templates available on: - http://extensions.services.**o**penoffice.org http://openoffice.org http://**extensions.services.**openoffice.orghttp://extensions.services.openoffice.org - http://templates.services.**op**enoffice.org http://openoffice.org http://templates.**services.openoffice.orghttp://templates.services.openoffice.org I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I
Re: extensions and translations.
see below please. On 1 November 2012 22:21, Rob Weir robw...@apache.org wrote: On Thu, Nov 1, 2012 at 5:07 PM, jan iversen jancasacon...@gmail.com wrote: Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files - is of interest to the general public in different countries - is willing to let the source be controlled/reviewed by committer. - accept a vote by the committers to be accepted If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. Please help me out here, I am not sure if that is enough for the apache way. There are probably two degrees of standard or official extensions. 1) An extension that is released with our binaries, e.g., it is available out-of-the-box, either automatically installed, or available as an option in the installer. That would be things like wiki publisher in swext, that still have the sun license and not the apache license. But that what actually what I was thinking about, and of course these extension MUST be part of the apache demands. We might include include in the setup package, but it should not be automatically installed, if that was the case the end-user would see it as an integrated part, and not an add-on. We should not take responsibility for the extension, but simply offer it. 2) An extension that is developed and released by the project, and published in the extension repository. This is the current standard and should not be changed. the add on is optional The process for these would be nearly identical, differing only on whether it is released standalone or bundled with the full AOO installer. and not to forget, the possibility of getting the UI translated and available all over the world. Can we collect statistics about which extensions is installed how often ?? -Rob Jan. On 1 November 2012 21:24, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/extensions/ http://www.openoffice.org/**extensions/ http://www.**openoffice.org/extensions/ http://www.openoffice.org/extensions/ how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang.
Re: extensions and translations.
Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/**extensions/http://www.openoffice.org/extensions/how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right. If I am right that they are not part of the general translation, then is that per design so or should it be different ? Yes, this is by design. Extensions are offered to extent your AOO install at any point of time. These are developed by people that do not have to belong to our project (when we put aside some exceptions). They can act independently. And therefore they are allowed to (or have to ;-) ) do all on their own; incl. translation. That applies for all extensions and templates available on: - http://extensions.services.**openoffice.orghttp://extensions.services.openoffice.org - http://templates.services.**openoffice.orghttp://templates.services.openoffice.org I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I can. Don't panic. That's a great goal and everybody is thankful to you for doing this task. Marcus
Re: extensions and translations.
On Sat, Oct 27, 2012 at 10:27:34AM +0200, jan iversen wrote: I agree with you, we should NOT put a new framework on extensions writer. I was thinking along the lines of make a new directory ./extras/extensions/source, with files extension name.known extension This will force the extension developer to release that file under the ALv2, because only ALv2 code can be committed. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpkFslOjxwNG.pgp Description: PGP signature
Re: extensions and translations.
Got it, as Marcus explained, this is not a path to follow, but now I can write in my document that is has been discussed. jan On 27 October 2012 14:47, Ariel Constenla-Haile arie...@apache.org wrote: On Sat, Oct 27, 2012 at 10:27:34AM +0200, jan iversen wrote: I agree with you, we should NOT put a new framework on extensions writer. I was thinking along the lines of make a new directory ./extras/extensions/source, with files extension name.known extension This will force the extension developer to release that file under the ALv2, because only ALv2 code can be committed. Regards -- Ariel Constenla-Haile La Plata, Argentina
extensions and translations.
While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/extensions/ how does that get integrated into the translation process ? As far as I can see the sources are not integrated into our build --all --with-lang. If I am right that they are not part of the general translation, then is that per design so or should it be different ? I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I can. rgds Jan I.
Re: extensions and translations.
On Sat, Oct 27, 2012 at 12:36:38AM +0200, jan iversen wrote: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/extensions/ how does that get integrated into the translation process ? They don't. They don't belong to OpenOffice source tree. Only the Presenter Screen, the Presentation Minimizer and the Wiki Publisher are the currently supported extensions by this Apache project (even though the versions you find in the extensions site are rather old, the Wiki Publisher has Sun's name in it!). The source code for these extensions is located in main/sdext and main/swext. The Report Builder (main/reportbuilder), the MySQL SDBC driver (main/mysqlc) and the PDF Import (main/sdext) extensions are in the source tree but they can't be released by this Apache Project due to license conflict in its dependencies. The extension code is under the ALv2, but the dependencies are copy-left. All other extensions in the extension site are third party extensions, with all kind of licenses, and are unrelated to the Apache OpenOffice project. As far as I can see the sources are not integrated into our build --all --with-lang. Because they are third party extensions. Regards -- Ariel Constenla-Haile La Plata, Argentina pgp5ca2Wl6Xxe.pgp Description: PGP signature
Re: extensions and translations.
Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/extensions/ how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right. If I am right that they are not part of the general translation, then is that per design so or should it be different ? Yes, this is by design. Extensions are offered to extent your AOO install at any point of time. These are developed by people that do not have to belong to our project (when we put aside some exceptions). They can act independently. And therefore they are allowed to (or have to ;-) ) do all on their own; incl. translation. That applies for all extensions and templates available on: - http://extensions.services.openoffice.org - http://templates.services.openoffice.org I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I can. Don't panic. That's a great goal and everybody is thankful to you for doing this task. Marcus
Re: extensions and translations.
On Sat, Oct 27, 2012 at 01:17:33AM +0200, jan iversen wrote: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). It has nothing to do with licensing. Even if the extension code and all its dependencies are under the ALv2, why should OpenOffice include extensions by default in the install set? This goes against the concept of an extension. The fact that now there are three supported extensions is just a question of old Sun/Oracle decisions to release these as extension and not integrated as part of the application. never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? This will break several concepts and things. Mainly extension developers have complete freedom about when to release updates, how to integrate translation in their extensions (use the configuration API and XCU files, use the resource API and Java-property-like files, etc.), most important what license to choose, etc. In short, you will have to implement a new framework and force extensions developers to use it. Besides several concerns, legal concerns among them. Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Programmability and extensibility has always been a priority in OpenOffice, just read the Developer's Guide and other parts of the wiki. I tend to agree that it will be useful for an extension developer a way to submit a set of resource strings and get them translated, as long as the extension developer is not forced with release/legal/other concerns. Regards -- Ariel Constenla-Haile La Plata, Argentina pgp5xJdU39Y2o.pgp Description: PGP signature
