On Mon, Jun 3, 2013 at 5:01 PM, RGB ES <[email protected]> wrote: > 2013/6/3 Andrea Pescetti <[email protected]> > >> On 02/06/2013 RGB ES wrote: >> >>> (Top posting, CC to dev, doc and l10n, not sure on which one it is better >>> to continue the discussion) >>> 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. >>> >> >> 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. >> >> 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. >> >> >> AFAIK, right now the only of those sub sites updated recently is the >>> French >>> one, though: several of those "portals" do not see activity since years. >>> >> >> Yes, but this does not mean that they are completely outdated: information >> in those pages is still current and relevant in most cases, and I think it >> makes sense to continue using it rather than "starting clean" there too >> (unless there are plans for a major rewrite). >> > > 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. >
Right. So this is not good for downstream consumers. Anyone who wants to modify and redistribute AOO on commercial terms would want to also modify and redistribute documentation. So we do a service for them if we can ensure the documentation is under the same permissive license as the code. As for managing the translations, one option is to do the authoring in English, then import the text (HTML or Wikitext) into Pootle and translate it that way. Then we can generate the translated websites without having translators deal with the HTML or wiki syntax directly. -Rob > 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? > > Regards > Ricardo > > > >> >> Regards, >> Andrea. >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> l10n-unsubscribe@openoffice.**apache.org<[email protected]> >> For additional commands, e-mail: >> [email protected].**org<[email protected]> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
