On Wed, Jun 5, 2013 at 12:02 PM, janI <j...@apache.org> wrote:
> On 5 June 2013 16:36, Claudio Filho <filh...@gmail.com> wrote:
>
>> Hi
>>
>> 2013/6/3 RGB ES <rgb.m...@gmail.com>:
>> > 2013/6/3 Andrea Pescetti <pesce...@apache.org>
>> >
>> >> On 02/06/2013 RGB ES wrote:
>> >>
>> >>> Do we want to "clone", for example, the documentation section on all
>> the
>> >>> localized sites, just translating it? On Sun times that was the idea,
>> with
>> >>> sub sites ("portals") like
>> >>> http://wiki.services.**openoffice.org/wiki/**Documentation<
>> http://wiki.services.openoffice.org/wiki/Documentation>
>> >>> http://wiki.services.**openoffice.org/wiki/DE/**Documentation<
>> http://wiki.services.openoffice.org/wiki/DE/Documentation>
>> >>> http://wiki.services.**openoffice.org/wiki/FR/**Documentation<
>> http://wiki.services.openoffice.org/wiki/FR/Documentation>
>> >>> etc looking almost the same on all languages.
>>
>> Ricardo, we can go by two ways, based in commom practice for mediawiki:
>> http://wiki.../Documentation and http://wiki.../Documentation/<lang> -
>> for localized pages from the core
>> http://wiki.../<LANG>/<anything> - for local/native texts.
>>
>> >> This can work. We also have this other infrastructure in place
>> >> http://wiki.openoffice.org/**wiki/Main_Test<
>> http://wiki.openoffice.org/wiki/Main_Test>
>> >> added by Claudio a few months ago. See
>> >> http://wiki.openoffice.org/**wiki/Template:Lang<
>> http://wiki.openoffice.org/wiki/Template:Lang>
>> >> to see how it works. I don't know which approach is best for our case.
>>
>> The *Template:* "technology" is for many other things, like menus,
>> sorts, and others. I think that we can use this first step based in
>> review the core and a way to translate it for other languages.
>>
>> How our system is a mediawiki, i did a research about localization in
>> this software with the last methods, where i found some interesting
>> contents. I believe that with translate extension for mediawiki we
>> have the tool for this goal.
>>
>>
>> http://commons.wikimedia.org/wiki/File:Making_Multilingual_Wikis_a_Reality_-_Niklas_Laxstr%C3%B6m_and_Claus_Christensen.ogv
>> http://www.mediawiki.org/wiki/Help:Extension:Translate
>> http://translatewiki.net/wiki/Translating:MediaWikie
>>
>
> I checked the extension, it is possible to install it on our mwiki.
>
>
>> >> As for keeping subsites synchronized, in theory this allows to have a
>> >> "Master copy" in English and then translate it in the various languages
>> as
>> >> volunteers become available. In practice, we can't stop someone from
>> >> editing or creating a translated page to add new content in a language
>> >> only, but ideally this would imply that the English version is updated
>> to
>> >> reflect the changes too.
>>
>> If i understood right, the translate extension will help us in this task.
>>
>> > All those "portal" pages are under PDL license (look at the categories at
>> > the bottom of those pages). If we want to promote new wiki content under
>> > Apache license, this means a problem. If I read this page right
>> >
>> > http://www.openoffice.org/licenses/PDL.html
>> >
>> > PDL is a sort of "copyleft" license.
>>We've tried to avoid this problem by starting new documentation in ALv2, not using the prior materials. And remember, if we want to borrow material, we have access to the complete Symphony documentation as well, which is included in the IBM SGA for Symphony. So all of that can be treated as ALv2. >> This is a excelent question. I ask to my self how the TDF did about >> (more) this question. Can we do like them? Simply overwrite the >> license and to continue the devel? (i remember when they copied all >> sites/docs/contents, like api site, and changed the license) >> > > I have seen similar things happen in other wikis. The way forward seems to > be > 1) announce the intention of changing license. > 2) request contributors who do not agree, to remove their pages (we have > mail adresses on the users) > 3) give contributors time to do it. > 4) change license. > This is overkill. There is no need to remove PDL pages. Maybe just move them if they are inconvenient? But if the content is relevant, why remove? The way forward is to respect the licenses as they are. We have greater latitude in what legacy licenses are used on the website than we do in the AOO product itself. We've had no problems at all hosting Creative Content licensed documentation, PDL content, etc., on the website, wiki, etc. Nothing has changed in that regard. However, when we create new material, including enhancements of existing material, then we need to respect the ICLA which says our contributions are made under ALv2. This might mean that going forward that modified content is covered by multiple licenses. This should not be a problem. > We should put the license in as part of "create user", as an "do you > accept", thereby we only have a problem with existing users. > This would be nice. > >> > Re-license those pages is not possible without the explicit consent of >> the >> > author, and those pages are so old that contact the authors is almost >> > impossible. Suppose we update those pages to point to the new material. A >> > potential contributor (or just a casual reader) will see the PDL notice >> on >> > the portal page, and no notice on the new pages: from the user >> perspective, >> > does this means that the new page is also under PDL? We know it isn't, >> but >> > this could be a cause of confusion, IMO. So, which is the best way to >> work >> > around this problem? Reimplement those pages, making a clear separation >> > between new material (under Apache) and legacy content? >> >> Maybe this is the unique way. By other hand, is a opportunity of >> review all content in the wiki, reorder and clean it, and evolve based >> in the correct license. In some cases, we can see the page history and >> try to find the author. Some parts, i believe that is all from >> Sun/Oracle copyright, so transfered to ASF. >> The website contents were not included in the SGA from Oracle. So the license is from the original authors. > > A cleanup would be nice independent of which way we go > > The word re-licensing is not a show stopper. > 1) We are not obligated to store those pages for ever, we can, with notice, > delete the pages > 2) We are allowed to copy the pages, with changes, and the new page can be > under a new license > In any case I'd love to have the problem where we have abundant AOO 4.0 documentation in English and our main concern was how to translate it. Regards, -Rob > rgds > jan I > >> >> My 2ยข >> Claudio >> >> --------------------------------------------------------------------- >> 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
