Hi, W dniu 07.12.2015 o 14:56, Daniel Naber pisze: > Hi, > > the year is slowly coming to an end, so I thought I'd try to summarize > what we've achieved this year and how we can move LT forward in the > future. In 2015, we... > > * made three releases so far (2.9, 3.0, 3.1), another one is planned > * more than doubled the number of visits to languagetool.org (January: > 156,000, November: 326,000) > * released a Chrome extension with more than 1,500 users now > * added support for ngram models to detect confusion of (mostly) > homophones (English, German) > * did several things I forgot to list here > * added and improved many language-specific rules. Specifically, 14 > languages are maintained if you define this as "had at least ten commits > in its grammar.xml and disambiguation.xml files this year". However, > this also means 17 languages are not maintained.
This is impressive overall! > > This last point of unmaintained languages highlights what I think is an > important issue: In the last three years, we increased our number of > users by a factor of 10. At the same time, the number of commits and > people who regularly contribute didn't grow at all (see attachment). > Many languages are not maintained, and even those that are often only > have a single contributor. If that contributor becomes inactive, finding > a new one seems almost impossible. If we continue like this, LT will > some day end up with very few languages that are actually maintained. As > there doesn't seem to be any correlation between number of users and > number of regular contributors, user growth won't help us. > > I have no solution for this problem, but some ideas I'd like to get > feedback on: > > (1) Clean up: throw out all unmaintained languages that also have less > than 100 rules. This way users don't get the false impression that their > language is supported when it actually isn't. It might also create some > motivation to contribute when users notice that "their" language is > being thrown out. > I'm strongly against. If there's already some initial support, getting less technical contributors is much easier. We could exclude such initial support in our releases, however, if that's supposed to help in getting maintainers. I think it would only mean wasted time and effort. > (2) Grow the contributor community: somehow find new contributors to > revive the unmaintained languages and find contributors to support the > maintainers of languages that are already doing well. The thing is: I > have no idea how to do this. For example, we have a text on > languagetool.org saying we're looking for help with marketing. This text > has been shown to more than 40,000 visitors and the effect so far has > been zero (actually four people have contacted me, but three of those > have already disappeared). What is holding people back from becoming a > regular contributor? Well, there's some learning curve, and that's why. I think there's a community that we haven't addressed at all: language professionals, be it proofreaders or translators (and translation agencies). Translators are using suboptimal tools, such as Apsic XBench, for their proofreading tasks. If we could get interest of technically savvy translators, we could get new contributors. This might also mean some input from commercial companies. > > (3) Crowdsourcing: give up on finding qualified contributors, instead > develop tools that allow contribution via very, very simple means, like > clicking on correct and incorrect sentences. It's not clear how well > this could work. It might be combined with (4). For it to work, we might need really lots of people... > > (4) Statistics: give up on finding qualified contributors and find > errors using ngram statistics etc. With statistics, finding errors is > language-independent. Quality might be worse than with hand-written > rules, but for languages that are not maintained anyway there are often > hardly hand-written rules. Of course, everybody could still contribute > manually written rules and maybe revive language support that way. > > (5) Business: develop a business model and pay people for working on LT. > This is difficult, developing a business is a full-time job on its own. > Even if it worked, it would only cover very few mainstream languages. > > These are the options I can think of that go beyond "let's just keep > going". Yes, we could just keep going - for some languages, LT is in > good health. But to be a sustainable project in the long term, I think > we need either more than one contributor per language or we need a > technological approach that works without a maintainer per language. > > Please, everybody, let me know what you think and what ideas you have > about the future of LanguageTool. I don't think varied level of support was ever a problem for LanguageTool. There will be minority languages with poorer support, and that's always the case. Yes, of course. Why worry? Life's too short. Regards, Marcin ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
