Merge lp:~max-rabkin/ibid/google-translate into lp:~ibid-core/ibid/old-trunk-1.6
Proposed by
Max Rabkin
Status: | Merged | ||||||||
---|---|---|---|---|---|---|---|---|---|
Approved by: | Jonathan Hitchcock | ||||||||
Approved revision: | not available | ||||||||
Merged at revision: | 821 | ||||||||
Proposed branch: | lp:~max-rabkin/ibid/google-translate | ||||||||
Merge into: | lp:~ibid-core/ibid/old-trunk-1.6 | ||||||||
Diff against target: |
182 lines (+59/-73) 1 file modified
ibid/plugins/google.py (+59/-73) |
||||||||
To merge this branch: | bzr merge lp:~max-rabkin/ibid/google-translate | ||||||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jonathan Hitchcock | Approve | ||
Michael Gorven | Approve | ||
Stefano Rivera | Approve | ||
Review via email: mp+16691@code.launchpad.net |
To post a comment you must log in.
Using a hard-coded language list means we can tell users which languages we support, and we can use a normal @match to extract the arguments. It also means we use Google's language codes, which are not the same as ISO 639-1: they use "iw" for Hebrew instead of "he" (but accept both), and other functions in the Language API use the ISO 639-2 code for Cherokee (there is no 639-1 code). Also, we can read the languages right there in the code, so no more surprises like Greek.
Of course, there are the usual disadvantages of hard-coded values: basically, when Google adds languages, we'll have to update the list.