Sorry for top posting... But yes, I was pretty much thinking along the lines Rob sketched out modulo TJ F. I can sound out these ideas. Political as well as resource issues come to mind, but I also see this as an opportunity to do some macro collaboration with, say, other projects engaged. In both localisation and ecosystem building. And as to the developer communities: always a challenge, but I do have many years doing just this sort of thing, only now there is no shroud of suspicion palling motive.
(Nonsense words? iPad's spellchecker.) -- Louis Suárez-Potts On 2011-12-10, at 20:06, TJ Frazier <tjfraz...@cfl.rr.com> wrote: > On 12/10/2011 19:44, Rob Weir wrote: >> On Sat, Dec 10, 2011 at 7:21 PM, Ross Gardler >> <rgard...@opendirective.com> wrote: >>> On 11 December 2011 00:13, Rob Weir<robw...@apache.org> wrote: >>>> On Sat, Dec 10, 2011 at 7:11 PM, Ross Gardler >>>> <rgard...@opendirective.com> wrote: >>>>> On 11 December 2011 00:02, Rob Weir<robw...@apache.org> wrote: >>>>>> On Sat, Dec 10, 2011 at 5:12 PM, Louis R Suárez-Potts<lo...@apache.org> >>>>>> wrote: >>>>> >>>>> ... >>>>> >>>>>>> Now to the present issue. I've written that I would rather focus here, >>>>>>> in Apache land, on coding. But that only opens the door, as it were, to >>>>>>> establishing the very successful Native Language modules either in >>>>>>> another wing of Apache (??) or outside the Apache frame but >>>>>>> corresponding to it, so that QA, a key element of the NL projects, for >>>>>>> instance, could be tied in. Licenses, etc., would have to be >>>>>>> harmonised. And I'd also suggest using a simpler work medium, such as >>>>>>> wikis. >>>>>>> >>>>>>> I think some of this is already going on but it is not clear to me >>>>>>> *what* is going on or where. I'm not alone. I have received several >>>>>>> pings on this very question, and I'd like to move on it. >>>>>>> >>>>>> >>>>>> >>>>>> I can see several models that could work: >>>>> >>>>> All good options... >>>>> >>>>>> You hint at another option. I'm not sure it would work, but let's >>>>>> list it for sake of argument: >>>>>> >>>>>> 4. NL projects are individually proposed as their own podlings. Their >>>>>> charter would be for them to produce localizations of AOO. But they >>>>>> would be autonomous PMC's within Apache, with their own website, >>>>>> mailing lists, etc. >>>>> >>>>> Why do you feel this would this not work? >>>>> >>>> >>>> You have many Gaelic or Vietnamese-speaking mentors? >>> >>> Fair point, although it is reasonable to expect that many of the >>> people involved will be bi-lingual at least (otherwise how can they >>> translate). Option 4 should not be ruled out (and you didn't do so), I >>> was just wondering what the source of your reservations was. >>> >> >> So a few other ways this doesn't quite fit a podling, as currently practiced: >> >> 1) Ability to find mentors, as mentioned above. >> >> 2) Ability of our infrastructure to handle non-ASCII collaboration. >> We've already seen, in our small attempt to have some Japanese NL work >> in this project, that Roller was not allowing Japanese text and that >> the SpamAssassin flags every attempted post to the Japanese language >> list as spam. I'd expect some work would be needed in several areas. >> But once done, this work would benefit others who attempt something >> similar. So not a bad thing to try. But I'd anticipate initial >> challenges of this kind. >> >> 3) Technical skills needed to produce a release. To get through the >> ceremony of cutting a release at Apache requires someone understand >> things ranging from SVN tagging to GPG signing. Translators are not >> coders. Their expertise is on the linguistic side. They are not >> command-line people. You might be lucky and have someone who can also >> be comfortable with these things, but it would not be guaranteed. >> >> 4) The efforts can be very small in some cases. How do you get three >> +1's for a release if there are only 2 people in your project? >> >> 5) Growing the community of developers is hard. Once you've >> translated 100% of the GUI strings, then what? Translate them again, >> better? And then better again? Put differently, the work of >> translation is finite and does not give much room for growth. >> However, on the other, non-release side of NL projects, the outreach >> to users, the website, etc., there is much room for growth. >> >> 5) This creates a quasi-umbrella project. Since translations are not >> usable separate from the core AOO code, these other new projects would >> be necessarily tied to the features and the schedule of AOO, assuming >> they are not forking the code itself. I've heard general unease with >> umbrella projects at Apache. >> >> But if we are willing to dream, you could imagine a kind of umbrella >> project, not of code modules, but of user-facing interactions, where >> autonomous groups within Apache maintained localized user-facing >> pages, wikis, user lists, support forums, etc. TLP might be too >> heavy weight for this, since we have potentially many dozens of these, >> and their releases would consist of translated strings that are only >> useful when installed with AOO. The non-release activities of the >> project would clearly be their focus. So this is something I don't >> think we've seen at Apache in a TLP. (We see them in foundation >> projects, but this is not that). Rather than squeeze it into an >> existing mold, maybe it needs a new something? >> >> -Rov >> >>> Ross >>> > Idea? Some of the problems would be minimized if the Native Language > Confederation (NLC) as a whole became a project. Perhaps Louis could sound > out some folks on this? > > -- > /tj/ >
