Integrate into KALanguageReport

[alani1]

I would love to integrate into KALanguageReport. Yes I know it is messy.

Have you been successful in setting up your own environment ? Else I would look into into it maybe this weekend. I am not worried too much about UnicodeIssues these can be sorted out or simply be ignored.

regards, Alain

[ulikoehler]

Bisher habe ich KALanguageReport noch nicht richtig zum laufen gebracht. Grundsätzlich sollte es aber funktionieren, mir fehlt aber der Django-Background, um das effizient schreiben zu können.

Ich habe heute nochmal darüber nachgedacht wie eine Integration am besten aussehen sollte.

• Ich finde, dass KATranslationCheck in jedem Fall auch alleine lauffähig sein sollte (falls es zum beispiel mal die pt_PT-Übersetzer benutzen wollen).
• Ich benutze relativ viele Py3k-Konstrukte und extrem viele Py2k-Konstrukte. Da ich den Anspruch habe, dass meine Software zumindest ein gewisses Maß an Robusheit bietet, halte ich es nicht für sinnvoll, Unicode-Fehler hier zu ignorieren. Py3k löst für mich insbesondere die Unicode-Fehler, die in externen Bibliotheken (polib etc). auftreten
• Grundsätzlich ist es absolut sinnvoll, in KALanguageReport (und in Zukunft evtl. auch auf der KA-Seite https://www.khanacademy.org/translations/de) Links zu Reports pro File zu integrieren, bzw. Zähler für Probleme anzuzeigen
• Meines Erachtens braucht das Skript bei weitem zu viel RAM und Rechenzeit (und Traffic) um dynamisch on-demand ausgeführt zu werden. Ich finde es sinnvoll, es weiter als statischen Seitengenerator aufzubauen.

Daher denke ich, dass die Folgende Herangehensweise sinnvoll ist:

• KATranslationCheck bleibt ein eigenständiges Tool und ein KALanguageReport-MgmtCmd führt dieses Tool (check.py -d) per subprocess aus. Dann ist man z.B. nicht daran gebunden, einen einzigen Python-Interpreter zu verwenden.
• Während der Geneierung der KALanguageReport-Seiten wird das JSON-API http://kacheck.localgrid.de/filestats.json verwendet, um die entsprechenden Informationen direkt zu holen.

Was hältst du von diesen Überlegungen?

[alani1]

Hi Uli,

KALanguageReport ist prinzipiell sprachunabhaengig, und lief mal fuer ganz viele sprachen siehe z.b.

http://www.kadeutsch.org/report/th/TestSiteStatistic.html

Der Report Generator von KALanguageReport ist kein dynamisches Script sonder laueft alle 15 Minuten fuer die deutsche Sprache. Ich kann durchaus damit leben dass KALangCheck auch eigenstaendig funktionieren soll, ich kann ja auch einfach deinen code integrieren, aber Py3 ist ein NoGo fuer mich da es noch keine stable debian distro gibt welche py3 unterstuezt. Man kann durchaus auch mit P2 stabilen code produzieren. KALanguageReport lief sogar auf chinesisch. Aber ja es ist muehsam. Ich habe leider nicht mehr allzuviel Zeit um mich um KALanguageReport zu kuemmern, wollte ihn eigentlich schon laenger in die Pension schicken, aber da KA momentan Probleme mit ihrem Portal hat maintaine ich ihn etwas weiter.

Deine Ideen sind gut, ich scheitere aber daran dass ich keinen P3 Interpreter habe.In dem Fall verzichten wir lieber auf die Integration, es ist auch so sehr nuetzlich. Ich werde ev. kurz mal versuchen wie aufwaendig ein backport auf py2 waere, dann sehe ich weiter.

btw, ich habe bei Crowdin ein Ticket betreffend dem alten File eroeffnet. Es scheint tatsaechlich vom Februar zu stammen. Das erklaert die false positives. Ich befuerchte sie werden uns aufs API verweisen, glaube kaum dass KA den API Key rausrueckt. I let you know.

2015-07-23 9:15 GMT+09:00 Uli Köhler notifications@github.com:

Bisher habe ich KALanguageReport noch nicht richtig zum laufen gebracht. Grundsätzlich sollte es aber funktionieren, mir fehlt aber der Django-Background, um das effizient schreiben zu können.

Ich habe heute nochmal darüber nachgedacht wie eine Integration am besten aussehen sollte.

• Ich finde, dass KATranslationCheck in jedem Fall auch alleine lauffähig sein sollte (falls es zum beispiel mal die pt_PT-Übersetzer benutzen wollen).
• Ich benutze relativ viele Py3k-Konstrukte und extrem viele Py2k-Konstrukte. Da ich den Anspruch habe, dass meine Software zumindest ein gewisses Maß an Robusheit bietet, halte ich es nicht für sinnvoll, Unicode-Fehler hier zu ignorieren. Py3k löst für mich insbesondere die Unicode-Fehler, die in externen Bibliotheken (polib etc). auftreten
• Grundsätzlich ist es absolut sinnvoll, in KALanguageReport (und in Zukunft evtl. auch auf der KA-Seite https://www.khanacademy.org/translations/de) Links zu Reports pro File zu integrieren, bzw. Zähler für Probleme anzuzeigen
• Meines Erachtens braucht das Skript bei weitem zu viel RAM und Rechenzeit (und Traffic) um dynamisch on-demand ausgeführt zu werden. Ich finde es sinnvoll, es weiter als statischen Seitengenerator aufzubauen.

Daher denke ich, dass die Folgende Herangehensweise sinnvoll ist:

• KATranslationCheck bleibt ein eigenständiges Tool und ein KALanguageReport-MgmtCmd führt dieses Tool (check.py -d) per subprocess aus. Dann ist man z.B. nicht daran gebunden, einen einzigen Python-Interpreter zu verwenden.
• Während der Geneierung der KALanguageReport-Seiten wird das JSON-API http://kacheck.localgrid.de/filestats.json verwendet, um die entsprechenden Informationen direkt zu holen.

Was hältst du von diesen Überlegungen?

— Reply to this email directly or view it on GitHub https://github.com/ulikoehler/KATranslationCheck/issues/2#issuecomment-123913345 .

[ulikoehler]

Du kannst ja einfach Anaconda mit einem py3k-Interpreter installieren (ist nur ein Ordner), dann kannst du das Problem mit dem fehlenden Interpreter umgehen. Oder auch mit zu alten Python2-Versionen. Du brauchst dann keine globale Installation und änderst nicht den globalen Interpreter, hast aber trotzdem eine aktuelle Version. Es gibt auch Alternativen zu Anaconda, aber mit denen habe ich noch nie gearbeitet.

Ich hatte zwar bei vielen Applikationen dasselbe Problem (stable-Distro x hat nicht Python-Version y, die ich brauche), aber dank Distributionen wie Anaconda sehe ich aktuell keinen Grund mehr, Legacy-Code für Py2k zu schreiben.

Mich stört an dem KA-Portal, dass es die Exercises nur alle 2 Wochen oder noch seltener aktualisieren (aktuell das letzte mal vor 13 Tagen). Da finde ich die 15min von KALanguageReport schon wesentlich sinnvoller.

Ja, man kann natürlich auch mit Python2 den Code produzieren, der irgendwie läuft. Aber nach meiner Erfahrung hat man damit letztendlich immer mehr Probleme mit Unicode als mit Py3k. Und die sind schwer zu fixen, wenn sie in irgendwelchen externen Bibliotheken sind

Dass das file vom februar stammt ist ziemlich schlecht :-1: . Mir fällt spontan nicht ein, wie wir das lösen sollten, bzw. wir müssen doch die "export single pot"-Variante machen (ob die wohl auch von Februar sind?)

[alani1]

also das einfachste ist einfach dein .json file zu laden und dann auf deinen Server zu verlinken, dann haben wir das sauber getrennt und haben keine Probleme mit Python interpreter. Und du kannst dich voll auf den KACheck konzentrieren der wirklich super geworden ist.

Das verlinken mache ich heute Abend.

Das mit dem File muessen wir anschauen, ich weiss nicht an wem das liegt entweder bei Crowdin oder KA als project owner. Ich warte auf die Antwort von Crowdin und dann schauen wir weiter. Hoffentlich muessen wir nicht so einen Hack machen mit dem "export single pot".

On Thu, Jul 23, 2015 at 10:49 AM Uli Köhler notifications@github.com wrote:

Du kannst ja einfach Anaconda mit einem py3k-Interpreter installieren (ist nur ein Ordner), dann kannst du das Problem mit dem fehlenden Interpreter umgehen. Oder auch mit zu alten Python2-Versionen. Du brauchst dann keine globale Installation und änderst nicht den globalen Interpreter, hast aber trotzdem eine aktuelle Version. Es gibt auch Alternativen zu Anaconda, aber mit denen habe ich noch nie gearbeitet.

Ich hatte zwar bei vielen Applikationen dasselbe Problem (stable-Distro x hat nicht Python-Version y, die ich brauche), aber dank Distributionen wie Anaconda sehe ich aktuell keinen Grund mehr, Legacy-Code für Py2k zu schreiben.

Mich stört an dem KA-Portal, dass es die Exercises nur alle 2 Wochen oder noch seltener aktualisieren (aktuell das letzte mal vor 13 Tagen). Da finde ich die 15min von KALanguageReport schon wesentlich sinnvoller.

Ja, man kann natürlich auch mit Python2 den Code produzieren, der irgendwie läuft. Aber nach meiner Erfahrung hat man damit letztendlich immer mehr Probleme mit Unicode als mit Py3k. Und die sind schwer zu fixen, wenn sie in irgendwelchen externen Bibliotheken sind

Dass das file vom februar stammt ist ziemlich schlecht [image: :-1:] . Mir fällt spontan nicht ein, wie wir das lösen sollten, bzw. wir müssen doch die "export single pot"-Variante machen (ob die wohl auch von Februar sind?)

— Reply to this email directly or view it on GitHub https://github.com/ulikoehler/KATranslationCheck/issues/2#issuecomment-123928212 .

[alani1]

Ok, integration is gemacht

[ulikoehler]

Super! Ich hoffe, dass die KA-Programmierer eine Idee haben wir man an die .po-Files rankommt.

[ulikoehler]

Ich würde auch davon ausgehen, dass es eine große Menge false negatives gibt, da im Februar viel noch nicht übersetzt war.

[alani1]

Ja, aber sobald wir die aktuellen Files haben erscheinen diese und dann können wir sie ja korrigieren. Habe heute den Bing 1 Fehler mit Search/Replace korrigiert, anstatt der 91 wie im Report waren es ca. 150

On Thu, Jul 23, 2015 at 10:08 PM Uli Köhler notifications@github.com wrote:

Ich würde auch davon ausgehen, dass es eine große Menge false negatives gibt, da im Februar viel noch nicht übersetzt war.

— Reply to this email directly or view it on GitHub https://github.com/ulikoehler/KATranslationCheck/issues/2#issuecomment-124090532 .