On Tuesday 16 September 2008 23:29:32 Mike McGrath wrote: > On Tue, 16 Sep 2008, Asgeir Frimannsson wrote: > > > > Thoughts and comments, all sorts of comments, are very welcome. > > > > > > Please correct me if I'm reading this wrong but I see "transifex is > > > great or close to it" and "here's how we're going to build our own > > > solution anyway" ? > > > > Yes, "Transifex is great and will continue to serve us". > > > > BUT: > > > > If you look at the state of the art in L10N outside the typical Linux > > projects where PO and Gettext rule, you'll notice we are very short on > > areas like: - Translation Reuse > > - Terminology Management > > - Translation Workflow and Project Management > > - Integration with CMSs. > > - Richer Translation Tools > > > > This is an effort in narrowing that gap, and I can't see that effort work > > by evolving an existing tool from this 'cultural background'. Yes, we can > > get some of the way by developing custom solutions for e.g. linking wikis > > to Transifex for CMS integration, or using e.g. Pootle for web-based > > translation. But we would still be limited to the core architecture of > > the intent of the original developers, which is something that would > > radically slow the project down. > > > > That said, I am not talking down Transifex, and the fact that someone in > > the community has sacrificed a lot and done a great job in getting us > > this far within Fedora. > > Correct me if I'm wrong though, instead of forking or adapting or working > with upstream, you are talking about doing your own thing right? We have a goal of where we want to see L10N infrastructure go, to enable us in the future to provide internal (translators paid by Red Hat) and community translators with tools to increase their productivity as well as better tools to manage the overall L10N process. If there is an 'upstream' that provides this, or a platform on to which we could develop this, then yes, we would consider 'working with upstream' or (in a worst-case-scenario) forking upstream. So to answer your question bluntly, YES - after 4 years involvement in industry and community L10N processes - I believe we can do better. But holding that thought, remember that this is in many ways 'middleware', and making use of e.g. the vast amount of knowledge invested in Translate Toolkit (file format conversions, build tools, QA) makes sense, and I'm not saying 'forget about all that we have invested in tools so far'. In addition, we are pulling in resources from other communities on this (JBoss, people in the L10N industry and academia), so we're not talking about or attempting to pull attention away from Transifex. (If so, we'd at least consider doing it in Python!). Still, we find it very important to develop this in the open and accept ideas and contributions from the wider community, including people in the Fedora infrastructure. Regarding building on top of Transifex, I think it is much better that these two projects 'compliment' each other in the near future. Someone with Dimitris' caliber, character, passion and vision is very rare (only flaw I can see in him is I think he's a Gnome guy, rather than a KDE guy - but I can see beyond that ;) ), and I honestly think it would be both wrong and counter- productive to attempt to 'hijack', fork or radically change core direction and architecture of a project that seems to finally gain traction way beyond the Fedora-circle. cheers, asgeir _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
