20101013

makemessages für den Lino-Kernel

Tilt! Ich habe verstanden, wie ich das folgende Problem lösen muss:

• Strings aus lino.modlib.fields.KNOWLEDGE_CHOICES werden von django-admin makemessages nicht gefunden, weil sie Teil des “Lino-Kernels” und keine direkte Django application sind. Ebenso lino.ui.extjs.ext_ui, lino.actions, lino.reports, … Rausfinden, ob man das nicht doch irgendwie automatisieren kann. Der Anfang ist gemacht in /Makefile. Siehe auch: 2010-10-08, https://www.lino-framework.org/topics/i18n.html

Ich muss einfach dafür sorgen, dass der “Lino-Kernel” inner- bzw. unterhalb von lino.modlib.system steht. Weil makemessages ja in den Verzeichnissen unterhalb jeder Django-Anwendung automatisch sucht.

Dazu gibt es zwei Wege: Aufteilen oder Zusammenfügen

1. Aufteilen

Ein Weg wäre, dass ich lino.modlib auslagere in ein neues Google-Projekt “lino-modlib” (oder “lino-contrib” oder “lino-apps”) mache. Nur das bisherige lino.modlib.system bleibt im Hauptprojekt und kommt dabei nach lino.

Also wenn INSTALLED_APPS bisher so aussieht:

INSTALLED_APPS = (
  'django.contrib.auth',
  ...
  'lino.modlib.system',
  'lino.modlib.countries',
  ...
  'dsbe',
  'south',
)

dann sähe sie nachher so aus:

INSTALLED_APPS = (
  'django.contrib.auth',
  ...
  'lino',
  'lino_apps.countries',
  ...
  'dsbe',
  'south',
)

2. Zusammenfügen

Ein Grund, der gegen Spaltung spricht ist die Tatsache, dass das für mich unnötiger Mehraufwand ist, solange ich der einzige Mensch bin, der an Lino arbeitet. Wenn ich diesen Weg wähle, wäre es logisch, dass lino-dsbe ebenfalls in die lino.modlib kommt. Die beiden Versionsnummern bei jedem Release gehen mir nämlich mittlerweile auf den Keks.

Wenn ich die lino.modlib nicht auslagern will, kann ich aber dummerweise in INSTALLED_APPS nicht einfach nur lino reintun (weil makemessages sonst für die Django-Anwendung lino auch die Meldungen aus der lino.modlib extrahieren würde), sondern alles was bisher unter lino steht (auch lino.ui) muss nach lino.core oder lino.base oder lino.main kommen.

Package	purpose
lino.main	include this in your INSTALLED_APPS
lino.tools	modules that might be usable without lino
lino.demo	example of a complete Lino site (“Django project”)
lino.test_apps	test cases for unit testing

Also Alternative ohne Auslagerung:

INSTALLED_APPS = (
  'django.contrib.auth',
  ...
  'lino.main',
  'lino.modlib.countries',
  ...
  'dsbe',
  'south',
)

3. Beides

Da fällt mir auf: makemessages hat doch eine Option –ignore! Also kann ich folgendes machen:

INSTALLED_APPS = (
  'django.contrib.auth',
  ...
  'lino',
  'lino.modlib.countries',
  ...
  'dsbe',
  'south',
)

Da habe ich die Vorteile beider Lösungen in Einem: in INSTALLED_APPS kann einfach nur lino stehen, und die lino.modlib braucht nicht in ein neues Codeprojekt ausgelagert zu werden.

Das sind freilich trotzdem einige Module und Verzeichnisse, die sich verschieben:

lino.modlib.fields -> lino.fields
lino.modlib.tools -> lino.tools
lino.modlib.fixtures -> lino.fixtures
lino.modlib.management -> lino.management

Daneben natürlich Änderungen in der /Makefile.

Die Umstrukturierung an sich war nur eine halbe Stunde Arbeit. Python ist super!

Resultat : make mm findet jetzt alle Meldungen, die übersetzt werden müssen. (Außer natürlich die Meldungen im JS-Code. Die sind ein anderes Kapitel, das kommt später mal.)

Aus “Notizen” werden “Dokumente”, “Links” und “Termine”

Und ich habe jetzt eine Vorstellung, die ich die folgenden drei Punkte angehen werde:

• NotesByPerson im Detail-Fenster einer Person sollte nur die wichtigen Ereignisse anzeigen (deren notes.NoteType.important eingeschaltet ist).

• Vielleicht auch eine grundlegendere Vorgehensweise: “Notizen” aufteilen in “Dokumente” und “Dienstleistungen”. Dienstleistungen halten fest, wann ein Mitarbeiter (Benutzer) für eine Person gearbeitet hat.

• Lokale Dateinamen benutzerfreundlich als Notiz erfassen. Eventuell neues Feld attached_file statt url? Eine URL kann man jetzt schon durch DnD der Adresse vom Browserfenster in ein Textfeld kopieren.

Die Wurzel des Übels ist, dass die Tabelle “Notizen” ein bisschen zu viele Dinge in den gleichen Topf wirft.

• “Dokumente” sind .odt-Dateien, die Lino generiert hat, und die oft vom Benutzer noch manuell bearbeitet worden sind. Ziel ist es, dass die Benutzer von Lino aus OpenOffice auf dem Dokument starten, darin arbeiten und es dann abspeichern— all das ohne sich um Dateinamen und -ordner kümmern zu müssen.

  Pro Dokument speichert Lino, ob und wenn ja wann es “ausgeliefert” wurde. Ein ausgeliefertes Dokument sollte ja normalerweise nicht mehr bearbeitet werden.

  Die Liste der Dokumentarten bleibt ungefähr gleich, außer dass Dokumentarten wie “Externes Dokument” da rausfliegen.

• “Links” sind Verweise zu externen Dokumenten. Im DSBE werden das vor allem .pdf-Dateien mit dem Bild eines eingescannten externen Dokuments sein. Vielleicht kommt noch eine neue Tabelle “Link-Arten” mit Einträgen im Stil:

  • Aufenthaltserlaubnis

  • Arbeitserlaubnis

  • Personalausweis

  • Vertrag

  • Sonstige

• “Termine” würden im DSBE zunächst nur benutzt, um sich von Lino Erinnerungen schicken zu lassen. Termin-Arten wären z.B. “Gültigkeit eines externen Dokuments läuft ab”. Allerdings müsste mir noch was einfallen, wie die Erstellung von Terminen möglichst automatisch vonstatten gehen soll. Statt dieser Tabelle könnte ich auch lediglich in den Links ein Datumsfeld reminder definieren. Wenn das ausgefüllt ist, kriegt der Benutzer an diesem Tag eine E-Mail geschickt. Das wäre die einfachste Lösung. Aber mit einer eigenen Tabelle von Terminen wäre die Sache flexibler und weitsichtiger.