I'll ask plainly what others are hinting at : Is this actually your own built service, or are you a proxy for something like Google Translate API[1]?
If it's your own built service, it's critical how you explain the hows and whys of your forecast availability and scalability numbers for your chosen architecture, given who you are competing with.
Alternatively, people can just download langid.py[1] and do language detection locally. This is not a particularly hard problem - I think it's doable by undergrad ML or NLP classes.
The tricky parts are usually political - are users going to be angry if you confuse Indonesian with Malaysian, or so on?
I think it's doable by undergrad ML or NLP classes.
In fact, we had a course for high school students where they learnt how a language guesser works and where they had to change a language guesser. A simplistic method that already works very well is:
* Create an n-gram fingerprint for each language by making a list of character uni-, bi-, and trigrams ordered by their frequency in a text. Retain the (say) 300 most frequent n-grams.
* To categorize a text, create a fingerprint for that text. Then compute for each language the sum n-gram rank differences. If an n-gram does not occur, the difference is the fingerprint size. Finally, pick the language with the lowest sum.
Of course, you can do fancier things, such as training a SVM or logistic regression classifier with n-grams and words as features, etc.
An interesting variation is to be able to distinguish different languages in a text. E.g. a Dutch text with English quotes.
Great point. Often overlooked by people who only know what I call "drive-by machine learning" (finished an online ML course or something).
There's a multitude of problems with real-world texts that a robust guesser must deal with gracefully: short texts; texts in none of the languages the "guesser" was trained for (is it able to return "none of the above?" or does it return a random one then?); texts in multiple languages (incl. common noun phrases phrases inserted into text in another language); texts with parts repeated multiple times (web pages and blogs in particular are a bitch!), which skews char/word distributions and messes up statistical models etc.
It's the same thing as with spelling correction, really. "But Norvig did it in 1.5 lines of Python!" See "A Spellchecker Used To Be A Major Feat of Software Engineering" at https://news.ycombinator.com/item?id=3466927
Spoiler: it still is, except for "drive-by ML apps".
Often overlooked by people who only know what I call "drive-by machine learning" (finished an online ML course or something).
A bit sour, are we? ;)
The point is that it is an NLP task where it is relatively easy to get good results on general text (see Cavnar and Trenkle). So, it is a fun and satisfying exercise.
Saying there is difficult noisy data is pointing out the obvious ;).
It's easy to write a language guesser, but's not easy to write a good one.
Obviously, it is highly domain and text length dependent (as I also mentioned in another comment).
But, e.g. Cavnar and Trenkle obtained a 99.8% accuracy on newsgroup articles in 14 languages using the method outlined above.
There are very few NLP tasks where you can achieve such high accuracy with relatively simple and understandable methods. That's why it is a nice subject for an NLP introduction to e.g. high school students.
I have worked in parsing and generation, where it is difficult to obtain satisfying results with many man years of work on newspaper text, let alone tweets or Youtube comments ;).
The design is fine, but the language used on the page itself isn't quite right.
I see three spelling errors in your language list:
- Panjabi should be Punjabi;
- Teligu should be Telugu;
- Ukraininan should be Ukrainian.
There are also a few grammar problems earlier in the document, and style problems (e.g. English doesn't use a space before sentence-ending punctuation marks).
It's probably overloaded because it's on hackernews and is based on the same features (character n-grams) as Google Translate. Your text is simply too short for character n-grams to be 100% reliable.
Looks interesting. Why not have a input on the landing page where someone can try it out without even signing up? I think then people could give it a spin before they give away their email address. Otherwise, the user just has to trust your 99% figure, which it might be helpful to give some data around, even if it is a footnote (on a corpus of x, over x period of time, etc.)
Also, I think it would be clearer if it said "A simple and scalable way to automatically classify text by language" instead of "A simple and scalable way to classify automatically text by language".
Design looks very clean though. Nice work.
EDIT: Also, your social media links at the bottom aren't hooked up yet.
Though, having implemented a language guesser myself, it's only an issue with very short texts (a few words). On longer texts models based on character n-grams achieve very high accuracies.
I've used detectlanguage.com[1] in the past, which seems like a very similar service to getlang.io. With both of them it is hard to know what is behind the scenes...
I wonder how this performs on short text posts like tweets. At my last gig where we did social media text analysis we used a few different packages (chromium, guess-language, and our own ngram classifier) and still had pretty low accuracy for tweets.
You guys might want to handle GET requests for /try URL(https://getlang.io/try) as well.currently it's returning "Server Error (500)" for GET requests.
I don't know why I can't stand this sentence "A simple and scalable way to classify automatically text by language". "Classify" and "automatically" need to switch places.
Language guessing is rather hard when few letters are used especially if you use statistical methods. I think after 20 something letters you enter >%95 accuracy zone. In a simple library I wrote ( https://github.com/ahmetaa/zemberek-nlp/tree/master/lang-id Works for 60 languages but no docs yet) , for Turkish and English test results are:
For 20 letters
TR=95.90 EN=94.96
For 50 Letters
TR=99.44 EN=99.53
If 50 letters are used in a Doc, it identifies about 20000 docs per second in a decent desktop.
If it's your own built service, it's critical how you explain the hows and whys of your forecast availability and scalability numbers for your chosen architecture, given who you are competing with.
[1]https://developers.google.com/translate/v2/using_rest#detect...