Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Wenn eine Session eröffnet wurde, muss es ein SessionEnd in irgendeiner Art geben. Ansonsten wartet die Basis bis zum Timeoutfehler.

Soweit ich das überblicken kann, wird die Sitzung auch in dem Fall beendet, da "respond" aufgerufen wird.

Wär ne tolle Sache!

Hab's mal auf die Wunschliste gepackt (@drhirn: zu finden jetzt am Anfang der Doku, vor der cref; ist m.E. übersichtlicher).

...sehe ich kritisch, da in den Rhasspy-Attributen bzw. sentences.ini beides erlaubt ist.

Mein Gedanke dazu:
Wie will man das in der Spracherkennung auseinanderhalten? Klar wird das gehen, wenn es in unterschiedlichen Variablen vorkommt, aber wenn nicht...?
M.E. ist es eindeutiger, wenn wir in der Kommunikation zwischen Rhasspy und dem Modul zumindest im Bereich Device-Namen, Gruppen (s.u.) und Rooms alles auf "klein" trimmen. Da brauchen wir eindeutige Kenner, sonst ist m.E. Chaos im wahrsten Sinne des Wortes "vorprogrammiert"...
(Das betrifft nur bestimmte Elemente, die sowieso unter der "Verwaltung" des Moduls standen; das sollte eigentlich in vorhandenen Installationen keine Aufwände erzeugen, da wir ja nicht mehr immer auf die Attribute zugreifen, sondern vorverarbeitete Daten verwenden, s.u.).
[OT]
Wegen des Speichereinwands:
Ja, das mit dem Hash kostet etwas Arbeitsspeicher, spart dafür aber vermutlich etwas Rechenleistung. Vorteil ist (m.E.) eine größere Transparenz bei der jetzt möglichen "Vermischung" der Quellen für Infos.
Hatte mal eine Diskussion mit Rudi betr. die attrTemplate, da meinte er nur sinngemäß, dass wir uns dieses Themas dann annehmen, wenn es wirklich viel Speicher kostet . Glaube kaum, dass wir mit den paar Daten da was grundlegend falsch machen, zumal, wenn die Daten (bei gDT-Mappings) vorher gar nicht in der Form existiert hatten ...
[/OT]

Der Standardraum sollte der SiteId entsprechen, welche im Standardfall genutzt wird und kein siteId="Küche" mitgegeben wird.Bei "set Rhasspy speak hallo" ertönt in diesem Raum ein "hallo". Bei mir ist es aktuell das Wohnzimmer. Dazu habe ich die hardgecodete Variable von "default" auf "Wohnzimmer" gesetzt.

RHASSPY habe ich rausgeworfen (s.o.), Rhasspy als Room-Name bleibt (für devspec im room-Attribut) erst mal (und m.E. auch langfristig) möglich, sollte aber für Rhasspy dann auf Übermittlung in Kleinschreibung umgebogen werden, wie das mit allen Raumnamen der Fall ist (s.o.).
Eine Änderung im Modulcode sollte in jedem Fall nicht erforderlich sein, jedenfalls, soweit ich das überblicken kann; dafür gibt es ja weiter die Option, in der DEF was anzugeben.

Da bei der Installation von Rhasspy, die siteId immer zuerst "default" lautet, würde ich vorschlagen, den Standardraum mit "default" bei undef vorzubelegen. Das würde Einsteigern das Testen mit "set Rhasspy (speak|textCommand|play|etc.)" erleichtern und schnell zum gewünschten Erfolg führen.Ist auf jeden Fall eine nützliche Erweiterung.

Das mit "default" als Standardraum habe ich mal (hoffentlich) reingebastelt, erscheint mir sinnvoll, ist aber noch nicht weiter auf Praxistauglichkeit getestet und eben jederzeit auch änderbar (s.o.).

Code Auswählen Erweitern

Zeile 2009:"    my $contenttype = q{application/json};"
Da ist mir aufgefallen, dass die Variable definiert wird aber keine Übergabe bzw. Auswertung stattfindet.

...berechtigter Einwand, ist weg...

p.s.Schau mal hier: https://forum.fhem.de/index.php/topic,113180.msg1130450.html#msg1130450Die Get-Variante von Roman (vv.) ist auch interessant. "Wann sind die Kartoffeln fertig?" könnte man mit "Der Kartoffel-Timer ist in 10 Minuten abgelaufen." beantworten.

Finde ich auch interessant!

Zum Anhang hier:
- "Hash-only"
Im laufenden Betrieb greift das Modul jetzt auf die interne Struktur zu, deren Erneuerung löst dann auch gleich ein updateSlots und Training aus (andere Optionen sind wählbar). Damit sollte nach einer Änderung an einem Device dann immer Rhasspy auch die aktuellen Daten haben (und z.B. dann klein geschriebene Räume zurückliefern, die dann zu den Angaben im Hash passen).
Ich hatte erst vor, den Hash zu verstecken, aber bis auf weiteres ist die Fehlersuche ggf. einfacher, wenn er ohne weiteres via list sichtbar ist. Auch später glaube ich, dass er offen sichtbar bleiben sollte, damit der Anwender sehen kann, was aus seinen Angaben da "zusammengebraut" wird...

- Die Sprach-Hashes werden jetzt "gemixt", die Struktur ist über die englische Variante strikt vorgegeben. Im Detail:
-- Wenn wir neue Hashes brauchen, müssen die im Modulcode vorgesehen sein, sonst geht es jetzt nicht mehr; (ich hatte ein paar Abstürze, weil die Sprachfile nicht zu dem paßte, was das Modul erwartete; das sollte im Echtbetrieb nicht vorkommen können...!)
-- Da, wo dann passende Elemente (SCALAR) in der cfg gefunden werden, werden die übernommen, wo nicht, bleiben die Vorgaben aus dem Modul;
-- Das ganze ist jetzt dreistufig, neu ist die Option, einfach bestimmte einzelne eigene Sätze an passender Stelle im JSON-Bereich "user" zu ergänzen. (Ist evtl. zu kompliziert zu erklären, (unisnniges) Beispiel ist anbei (auch ein engl. "Rest", der nicht überschrieben ist). Die alten Fassungen sollten aber auch weiter funktionieren, und wenn das als zu schwierig empfunden ist, sollten wir es bei zwei Stufen belassen).)

- Es gibt eine neue Kategorie "groups", wie bei den rasspyRooms wird entweder das "allgemeine" group-Attribut ausgewertet, oder das ganze überschrieben durch rasspyGroups, falls gesetzt. Ziel ist es, je einen SetOnOffGroup-intent und SetNummericGroup-intent möglich zu machen. Man könnte das ganze eventuell auch über structure abbilden, aber das ist uU. sehr viel mehr Aufwand, als es über ein schnell mal vergebenes Schlagwort zu machen. Ggf. muss dann aber auch eine Verzögerungsmöglichkeit (send_delay) rein, damit es nichz zu "Funkhackel" kommt...

- Die genericDevType enthalten jetzt auch "media" (ungetestet, aber sollte mit den Vorgaben von https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV passen);

- Es ist mal eine Art ToDo/Wunschliste eingepflegt, dann kann man die Dinge ggf. auch leichter priorisieren und findet die Quelle schneller;
Im Moment stehen da u.A. drauf:
-- Timer/Wecker mit "label"-Option, geänderter Rückmeldung und Funktionalität.
-- Gruppen Schaltung (s.o.)
-- siteId2Room: Das ist in der heutigen Form zu starr, wenn man mobile Geräte verwendet. Ziel wäre, entweder den Standort (z.B. des Androiden) per Perl-Funktion bestimmen zu können oder einfach sagen zu können: "ich bin jetzt im Wohnzimmer". Über Details wäre zu reden...
-- "rhasspySpecials":
Habe keinen besseren Begriff gefunden, aber im Kern geht es darum, einen Ort anzubieten/vorzuhalten, um z.B. für das siteId2Room-Feature eine (Erst-) Eingabemöglichkeit zu haben. Weiterer Anwendungfall könnte ein "Lamellen-ad-on" sein (hier gibt es einige Jalousien mit separat verstellbaren/drehbaren Lamellen. Die Anweisung: "Fahre die Jalousie xy auf 50%" ist unvollständig, weil der "Drehungsanteil" fehlt - der zudem teilweise noch an ein ganz anderes Gerät gehen muss...
(Ein weites Feld; falls jemand funktionierende Lösungen hat?...).
Dann: bei manchen Geräten war bisher die Erkennung noch nicht optimal, und bei vielen von diesen Geräten wäre es super, erst noch eine Bestätigung vorzuschalten. In den Shortcuts ist das vorbereitet, aber "jemand" müßte es fertig machen und dann eben auch z.B. für SetOnOff an einzelnen Geräten (oder Gruppenschaltungen ) möglich machen.

Bzgl. weiterem Vorgehen:
Ich würde mich bei Gelegenheit um die Themen Gruppen (Prio 1) und Bestätigung (Prio 2) kümmern, wäre nett, wenn jemand anderes das Timer-Thema gut fände . Codeschnippsel sollten m.E. in Twilight zu finden sein, da gibt es z.B. die Prüfung, ob ein neu errechneter Sonnenuntergang (wg. Wetter) früher ist als "jetzt" - sowas bräuchte man vermutlich für den "Wecker" auch: Wird der um 17:00 Uhr auf 09:00 Uhr gestellt, ist vermutlich der morgige Tag gemeint...

Happy Testing .

[JensS]

Hey, cool - das Schweizer Taschenmesser! 
Danke für die schlüssigen Ausführungen. Da folgen wohl einige neue Hauptversionen.

Code Auswählen Erweitern

   if ($mute)...habe ich wohl überlesen - sorry.

Gruß Jens

p.s.

Die Anweisung: "Fahre die Jalousie xy auf 50%" ist unvollständig, weil der "Drehungsanteil" fehlt

Nur mal aus Interesse; wie würde die ganze Anweisung aussehen?

[Beta-User]

Anbei wieder was neues...

Das kann jetzt (prinzipiell) Gruppen an- und ausschalten, und bei shortcuts eine Bestätigung abfragen .

Details (auch zu den weiteren Attributen) liefere ich nach, bitte melden, falls direkt Informationsbedarf besteht.

- Gruppen werden aus den normalen group-Attributen abgeleitet, man kann das übersteuern über das neue (globale) rhasspyGroup-Attribut. Wie üblich muss man Rhasspy über update devicemap mitteilen, dass es was neues gibt...
sentences.ini dazu:

Code Auswählen Erweitern

[de.fhem:SetOnOffGroup]
\[(schalt|mach|fahr)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] $OnOffValue{Value}


Das ganze auch für SetNumeric umzusetzen, wird vermutlich etwas schwieriger, es wäre ggf. nett, wenn ihr Rückmeldung geben könntet, ob das in dieser Form für euch Sinn macht.

- Das mit der Confirmation braucht:a) eine entsprechende Anforderung, das ist im Moment nur für Shortcuts testweise implementiert:

Code Auswählen Erweitern

attr rhasspy shortcuts i="ton aus" f="set Yamaha_Main mute on" c="Soll ich wirklich den Verstärker still schalten" ct=10\
ton an={fhem ("set Yamaha_Main mute off")}
Relevant sind hier "c" (und optional "ct"), Erläuterungen zu den Parametern (Shortcuts insges.) sind als Kommentar im Code zu finden.
b) sentences.ini:

Code Auswählen Erweitern

[de.fhem:ConfirmAction]
(ja mach | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode}

Das ganze ist recht generisch aufgebaut, es sollte sich praktisch ohne größere Aufwände bei allen "Einzelanweisungen" ergänzen lassen (vorausgesetzt, man hat einen Ort, um die Info unterzubringen, dass man nur nach Bestätigung ausgeführt haben will). Was scheinbar nicht klappt, ist die Session ordentlich zu beenden, ich weiß aber noch nicht warum.

PS:
Bin wirklich positiv überrascht über den Rhasspy-Dienst an sich. Es scheint auch so zu sein, dass die Erkennung mit zunehmender Zahl an zu verarbeitenden Worten/Schnipseln eher besser wird...?

p.s.  Nur mal aus Interesse; wie würde die ganze Anweisung aussehen?

Das kommt zu allem Überfluss auch noch auf das konkrete Gerät an... Erfahrung habe ich jetzt mit zwei Fibaro-Modellen:
Der FGRM222 ist ein "Einheitsdevice", das dann die Befehle dim oder positionBlinds für die Öffnung kennt und positionSlat für die Drehung.
Der FGRM-223 ist ein "Mehrkanaler", von dem ich Kanal 1 für die Öffnung (hier nur: dim) verwende (das ginge auch über den Hauptkanal), und Kanal 2 für die Drehung, dort auch wieder über den dim-Befehl....

[drhirn]

Wie ihr merkt, habe ich zur momentan leider nicht wirklich Gelegenheit, mit euch am Modul zu arbeiten. Wird wieder anders hoffe ich.

Auf jeden Fall habe ich mal die neuesten Änderungen von Beta-User in eine Version 0.4.6a gepackt.

[Beta-User]

Paßt schon.

Du musst halt rechtzeitig "stop" rufen, falls das aus deiner Sicht in die falsche Richtung geht...

Werde mir dann mal den Wecker vornehmen , und dann eventuell irgendwann mal SetNumericGroup.

@all: Testet denn grade jemand an der aktuellen Version rum?
Habe gesehen, dass mind. einer (@Hardlife) grade dabei ist, sich in das Thema Rhasspy reinzufieseln, und fände es schade, wenn er sich noch allzulange mit der "klassischen" Konfiguration rumplagen würde... Statt alle in den room Rhasspy zu packen, einfach die devspec entsprechend wählen (das kann auch eine kommaseparierte Einzelauflistung von Devices sein!), jeweils genericDeviceType festlegen, und es wird in geschätzt 60%+ schon das meiste gewesen sein. Bißchen Raum- und Gruppenzuordnung, that's all .

[drhirn]

Ich hab keine Einwände. Ich täte nur Timer/Wecker trennen. Weil, ein Wecker kann durchaus komplex werden ("wecker jeden mittwoch um 08:30").

Bzgl. Groß-/Kleinschreibung unterstütze ich die Kleinschreib-Fraktion. Modulintern sollten wir alles klein behandeln, was wir verarbeiten müssen.

Soll ich eine neue "stable" machen und die als Hauptversion in GitHub markieren? Dann kommt keiner mehr auf die Idee, eine alte Version zu nehmen.

Durch meine ungewollte Abwesenheit bekomme ich leider viel nicht mit. Es wäre daher superpraktisch, wenn jemand von euch in der README/CRef mitdokumentieren würde damit wir nichts vergessen.

[Beta-User]

Ich hab keine Einwände.

Danke für die Rückmeldung!

Ich täte nur Timer/Wecker trennen. Weil, ein Wecker kann durchaus komplex werden ("wecker jeden mittwoch um 08:30").

An sich ein korrekter Hinweis. Zwei Gedanken dazu:
a) er kam "zu spät", da war der Code im wesentlichen schon umgestellt... (könnte man auch wieder ändern, falls gewünscht), aber
b) glaube ich, dass das mit dem komplexen Wecker-Wunsch zwar kommen wird ist, aber recht schwierig umzusetzen sein wird. Will mal wieder niemanden abhalten, zu beweisen, dass es doch geht, aber m.E. ist da recht viel Interaktion erforderlich, von daher macht man sowas m.E. lieber auf die "analoge" Weise per Frontend?
Timer/Wecker würde ich auf den Bereich bis 24h beschränken, und dafür lieber die Option vorsehen, über (das bereits in Teilen implementierte) Feature "$label" iVm. "specials" auch andere Aktionen auszulösen (also den speak-Befehl durch was anderes zu tauschen (oder zu ergänzen) - dann wäre evtl. auch das "Spiele eine WAV zum Zeitpunkt x ab" recht einfach umzusetzen...

Bzgl. Groß-/Kleinschreibung unterstütze ich die Kleinschreib-Fraktion. Modulintern sollten wir alles klein behandeln, was wir verarbeiten müssen.

Thx.

Soll ich eine neue "stable" machen und die als Hauptversion in GitHub markieren? Dann kommt keiner mehr auf die Idee, eine alte Version zu nehmen.

Wenn, dann m.E. die hier angehängte...
Ist aber eben noch recht wenig getestet.

Durch meine ungewollte Abwesenheit bekomme ich leider viel nicht mit. Es wäre daher superpraktisch, wenn jemand von euch in der README/CRef mitdokumentieren würde damit wir nichts vergessen.

Das wäre jetzt dann der nächste Schritt, werde das mal bei Gelegenheit angehen.
Bis dato sollte das meiste mit der "alten" Anleitung funktionieren, nicht dokumentiert sind eher die neuen Sachen...

PS: die sentences für den Wecker:

Code Auswählen Erweitern

[de.fhem:SetTimer]
( timer | wecker ) [$TimerNames{label}] auf [((1..60){hour} (stunde|stunden) | (1..24){hourabs} (uhr) )] [und] [((1..60){min})]
( timer | wecker ) [$TimerNames{label}] auf [((1..60){hour} (stunde|stunden) | (1..24){hourabs} (uhr) )] [und] [((1..60){min} (minute|minuten))] [und] [((1..60){sec} (sekunde|sekunden))]
( timer | wecker ) [$TimerNames{label}] auf (1..60){hour} (einviertel{min:15}|einhalb{min:30}|dreiviertel{min:45}) (stunde|stunden)
( timer | wecker ) [$TimerNames{label}] auf (1..60){min} (einviertel{sec:15}|einhalb{sec:30}|dreiviertel{sec:45}) (minute|minuten)
Der slot $TimerNames muss separat angelegt werden und kann beliebige Schlagworte enthalten.

[Beta-User]

Vorgezogene Doku

wie generiert man Text -> Sprachausgabe nach den neuen Updates. D.h.erzeugt eine Sprachausgabe ?
[...] Version 4.6a.

Kommt darauf an:
Shortcuts ("alte" Syntax ) und CustomIntent:

Code Auswählen Erweitern

ton aus={fhem ("set lampe1 off")}In beiden Fällen wird Perlcode ausgeführt. Was da zurückkommt, sollte als response verwendet werden (=>wenn es nicht klappt, ist es ein bug), ausgenommen der Fall, dass "nichts" (echtes undef) zurückkommt; dann sollte die "DefaultConfirmation" ertönen.

Shortcuts neu enthält dann noch die Option, bei erfolgreicher Ausführung "r:" anzugeben, und da die Response reinzuschreiben.

[drhirn]

dann wäre evtl. auch das "Spiele eine WAV zum Zeitpunkt x ab" recht einfach umzusetzen...

Mein ursprünglicher Plan war sowieso, eine WAV abspielen zu lassen. Und zwar so lange, bis man sie mit "stopp(e den Timer)" stoppt. Deswegen auch die playWAV-Geschichte. Die Sprachausgabe war nur eine Übergangslösung.
Ich kam nur nicht dazu, das umzusetzen. Und mir fehlt eine brauchbare WAV-Datei. Falls jemand eine hat, nur her damit. Und ich weiß nicht, wie man die solange wiederholen könnte, bis eine Stopp-Anweisung kommt.

Wenn, dann m.E. die hier angehängte...

Erledigt

[Beta-User]

Übergangsweise: Die "Flasche" von JensS? (Für die "finale Fassung" müßte man was copyright-unverdächtiges suchen, evtl. irgendeinen (konvertierten) Linux-Systemsound?)

Das mit dem "Stop" bringt mich auf einen weiteren Ast:
- Das Default-Abspielen könnte man in eine at-Schleife packen, wobei ich die Zahl der Wiederholungen nicht bei Unendlich sehe.
- "Stop" sollte eine Anweisung unterhalb des SetTimer-intents sein, dann kann man das at gezielt "abschießen"; das wäre sowieso ein Thema, denn- "Cancel" könnte noch ein weiterer Zweig in SetTimer darstellen, mit dem man den Timer löscht.

Die ganze Logik würde sich dann erweitern, indem erst geschaut wird, ob eines der beiden "Keywords" in $data drin ist (siehe den Shortcuts-Code zu "confirm"). Das sollte dann auch direkt mit "$label" "spielen" können...

[drhirn]

Ziemlich genau so war mein Plan.

[Beta-User]

Ist 0.4.6a die aktuell "stabilste"?
also immer die, die man erhält, wenn man hier
https://github.com/drhirn/fhem-rhasspy
hin geht?

Na ja, wie "stabil" die ist, wird man sehen, da steht jedenfalls die version die ich heute morgen hier angehängt hatte...

Hier wäre jetzt eine im Angebot, die eine aktuelle cref enthält, die bisher verfügbaren Attribute und Optionen etwas ordnet und die Syntax an sich erklärt, vom Code her ist das ausnahmsweise mal unverändert. (die html-Konsistenz ist noch nicht geprüft)

Es wäre daher nett, wenn du die nehmen könntest (bis drhirn das auch nochmal durchgegangen ist und/oder wieder was neues via der von dir genannten github-Stelle kommt), dann kannst du nämlich auch gleich Rückmeldung geben, ob alles halbwegs stringent erklärt ist, auch zur Vorgehensweise bei der Einrichtung und so...

Ziemlich genau so war mein Plan.

Dann mal nur zu !

[JensS]

Was haltet Ihr davon, die Sprachdatei per Knopfdruck in fhem/FHEM zu generieren?
Die Hashes dazu wären bereits da, die Sprache wäre auch bekannt und als User müsste man nicht auf die Konsole.
Zum editieren würde man über "Edit files -> Own modules and helper file" rankommen.

@Beta-User
Mit den Rechten an der Flasche hast Du natürlich recht. Da war ich wohl zu voreilig.

Gruß Jens

[Beta-User]

Was haltet Ihr davon, die Sprachdatei per Knopfdruck in fhem/FHEM zu generieren?
Die Hashes dazu wären bereits da, die Sprache wäre auch bekannt und als User müsste man nicht auf die Konsole.
Zum editieren würde man über "Edit files -> Own modules and helper file" rankommen.

Wäre nicht das große Problem, aber:
- Der Befehl, um schnell mal einen Export zu machen ist jetzt schon in der cref drin .
- Mittelfristig wäre es gut, eine kleine Sammlung via svn/contrib verfügbar zu machen. Von da kann man sie mit einem speziellen Befehl auch direkt (mit passenden Rechten) aus FHEM runterladen. Aber auch dafür sollte cref eigentlich ausreichend sein.

Mit [...] der Flasche

Kein Problem; ist ja nur ein Schnipsel... Mir geht es halt darum, da für die "offizielle Fassung" gar nicht erst in irgendeinen Graubereich zu kommen.

[Beta-User]

Also, welche FHEM-Rhasspy-Version soll ich den nun nehmen?

Schon alleine wegen der cref: Mit ziemlicher Sicherheit => die letzte hier angehängte!
(EDIT: Ist nun auch im git unter https://github.com/drhirn/fhem-rhasspy/blob/0.4.6a/10_RHASSPY.pm verfügbar.)

Jetzt will ich natürlich nicht je zwei Satelliten nebeneinander haben, einmal Deutsch, einmal Spanisch. Also ist mein Ziel derzeit (neben dem langfristigen, das mir mal im Code anzuschauen, siehe Thread in der rhasspy Community) das Ganze via MQTT-Bridging hinzubekommen (meine bisherigen Anstrengungen siehe auch dort drüben).

Ich _glaube_, dass es möglich sein sollte, zwei (oder mehr) rhasspy-Dienste parallel laufen zu lassen (auf derselben Plattform), einen mit de-profile und einen mit "es", das ganze über einen Broker.

In der aktuellen cref sind ein paar Hinweise drin, wie ich _glaube/mir nach jetzigem Stand vorstelle_, dass man mehrere RHASSPY-Instanzen auf einem FHEM laufen haben kann.

Und falls drhirn/Beta-User soweit lesen: der Group-seperator wird in die site-id eingetragen und so trennt sich Gruppen- und Raumnamen. Entweder kann man das in den FHEM-rhasspyRoom-Attributen irgendwie mitgeben, oder aber man muss eben die site_id (Gruppe-Trenner-Name) und den echten Namen eintragen; einmal zu lernen und einmal falls man keinen Raum sagt und man den Raum, wo sich der Satellit befindet meint. Wenn ich sowas mal ernsthaft braucht, formuliere ich das besser.

Das habe ich nicht verstanden, ich würde optimalerweise MQTT-Rohdaten benötigen (siehe die Beispiele im Repo von drhirn), dann wird es evtl. klarer.

(Ich will nicht in dem anderen Thread zu viele Anwenderdetails diskutieren, die ich sowieso vermutlich noch nicht im Detail nachvollziehen kann; wenn es spezielle Themen gibt, die mit Mehrsprachigkeit zu tun haben, bitte melden und ggf. einfach einen neuen Thread dazu aufmachen?)