Das multilingual Plugin kann Übesetzungen per tag mittels {{!<lang>}}<text>{{--}} bereitstellen. Will man zum Beispiel eine englische und eine dänische Version des Textes anbieten, so schreibt man: "{{!en}}English version of text{{--}}{{!da}}Dansk version af tekst{{--}}" in das input Feld.
Getagte Übersetzungen haben den Vorteil, dass sie u.a. auch in der Seitenleiste verwendbar sind, so dass jeder editierbare Inhalt (in der Regel der Titel) von einem Seitenleisten Element auch übersetzt werden kann. Dies erstreckt sich per Option auch auf den Blog-Titel und Untertitel.
+ +Auch Theme eigene Optionen wie eine Navigationsleiste könnten so einfachst für verschiedenen Sprachen multilingual genutzt werden. Allerdings muss dann per Handarbeit der Smarty Modifier "|multilingual_lang" der entsprechenden Ausgabevariable in der Theme eigenen index.tpl per {$navlink.title|multilingual_lang} hinzugefügt werden.
Eine getagte Übersetzungen für Blog Einträge kann ebenfalls benutzt werden, ist aber in den Plugin Optionen standardmäßig deaktiviert, da sie bereits im Plugin vorhandene Funktionalität dupliziert. Getagte Übersetzungung sind bereits durch die Verwendung eines Datenbank basierten Ansatzes implementiert, und sie sollten entscheiden, welche Vorgehensweise sie beim Erstellen ihrer Einträge bevorzugen. Mit der gleichzeitigen Benutzung von beiden Ansätzen könnten am Ende seltsame und verwirrende Funktionalitäten enstehen. Die per default genutzte Datenbank basierende Methode nutzt das entryproperties Plugin das installiert sein muss. Hier wird der Eintrag in der default Blogsprache wie bisher auch erstellt und gespeichert. Dann kann man denselben Eintrag nutzen, übersetzen und mittels des neuen Sprachauswahlfeldes in der neuen Sprache abspeichern. Die übersetzte Variante befindet sich nun als entryproperties Eintrag in der entryproperties Tabelle. Im Frontend kann ein einzelner Blogeintrag mittels eines "Footer Links" leicht in der Sprache gewechselt werden. Dieses Verfahren hat keine Auswirkungen auf die Darstellung des Blogs, so wie es das Sprachen-Auswahlfeld des Seitenleisten Plugins hat, außer man aktiviert dies als Option. Zugriff auf die übersetzte Variante des Eintrags im Backend erhält man, in dem der originale Default Sprach Eintrag wie gewohnt aufgerufen, dann aber mit Hilfe des Sprach-Auswahlfeldes und des Buttons "Sprache wechseln" in den bereits übersetzten Eintrag gewechselt wird.
+ +Beachten sie auch, dass eine getagte Übersetzung mittels des Multilinguial Plugins nur tatsächliche Sprachblöcke betrifft, andere Sprachen aber keinen Fallback haben, so dass dieser Sprachteil dann immer leer zurückgegeben wird. Das heißt, sie sollten immer nur so viele Sprachen im Seitenleisten Plugin erlauben, wie sie auch als tag zur Übersetzung tatsächlich zur Verfügung stellen.
+ +Für Staticpages nutzen sie bitte das dort eingebaute Sprachen Auswahl Feld und erstellen damit jeweils eine eigene Staticpage per Sprache! Diese wird bei der Darstellung im Frontend je nach eingestellter Sprache automatisch erkannt. Dies ist unterschiedlich zum oben genannten Blog Eintragsverfahren! Sprach: 'ALL' Felder in den statische Seiten werden überall angezeigt.
+ +Abhängigkeiten für:
+ +Bitte beachten sie auch:
+ +++Wenn die Option "Sprache des Browsers eines Besuchers verwenden" in Serendipity aktiviert ist, überschreibt diese die aktuelle Spracheinstellung - und die aktuelle Spracheinstellung ist immer das, was Serendipity als "default" Spracheinstellung darstellt und auslegt. Es obliegt den Blog Autoren streng darauf zu achten, dass derjenige immer mit demselben Setup in der Spracheinstellung agiert, wenn ein Eintrag editiert wird. Ansonsten kann es zu unvorhergesehenen Problemen und sogar Eintragsverlusten führen.
+
++ + + \ No newline at end of file diff --git a/serendipity_event_multilingual/documentation_en.html b/serendipity_event_multilingual/documentation_en.html index fe68e574..4b8482c8 100644 --- a/serendipity_event_multilingual/documentation_en.html +++ b/serendipity_event_multilingual/documentation_en.html @@ -1,15 +1,50 @@ - + + -Zusätzlich sollten sie als Admin des Blogs, die "Globale Konfigurations" Blog Sprach-Variable und die "Persönliche Einstellungen" Sprach-Variable gleich setzen und weiterhin im Frontend keine Seitenleiste Sprach-Selektion setzen. Ansonsten kann es durch das gesetzte Cookie zu unvorhergesehenen Problemen in der Sprachdarstellung kommen.
+
The multilingual plugin supports tagged translations by the use of {{!<lang>}}<text>{{--}} tags. So if you want to write text with an english and a danish version, for instance, you can write: "{{!en}}English version of text{{--}}{{!da}}Dansk version af tekst{{--}}" into the input field.
Tagged translation have the advantage of being usable in the sidebar for example. So any editable content (typically the title) of a sidebar item can be translated as well. It even extends to the blog title and subtitle.
+ +Also theme based options like a navigation bar may be used tagged multilingual very easily. For this case you have to manually edit your themes index.tpl and add the Smarty Modifier "|multilingual_lang" to the variables in question per {$navlink.title|multilingual_lang}.
Tagged translation for blog entries is also available, but is disabled by default, as it duplicates functionality already present in the plugin. Entry translation is already implemented by use of a database based approach, and you should decide on which approach you prefer when creating entries. Using both approaches at the same time could end up being weird and confusing. The database implemented method uses the entryproperties plugin, which has to be installed first. Using this default method you have to write and save your entry as ever in the default blogs language. Then you can use the same entry, translate its content and title, select the language in the new language select field and save the entry again. This translated entry variant is now saved to the entryproperties database table. In the blogs frontend you can easily switch the translation variant by entry in the entries footer language links. This entry based lang switch has no change inheritance to the general blogs language, like the sidebar languagechooser field has, if not set by option. To get access to the translated entry version in the backend, open the origin lang blog entry in the entry form, select the translated language and hit the button "Select language". This will bring up the translated entry variant. Now you can edit and save this entry in purpose.
+ +Also be aware that tagged translation works by simply stripping out any language blocks that are not the current language. There is no fallback language in this case and means to only allow that much languages for the users to switch in the sidebar, that you already tagged.
+ +For staticpages use its language select field and emit one single staticpage per language! This will be automatically evaluated in the frontend language. This is handled differently to the blog entry approach! Lang 'ALL' field staticpages are shown in any case.
+ +Dependencies for:
+ +Please also pay attention to:
+ +++If the "browser language detection" option is enabled in Serendipity, this actually overrides the current language - and the current language is always what Serendipity displays and describes as "default" language. It currently actually relies on the blog editors to have the same setup of their language whenever they edit an article, else it would lead into problems or may loose data.
+
++ - + \ No newline at end of file diff --git a/serendipity_event_multilingual/lang_bg.inc.php b/serendipity_event_multilingual/lang_bg.inc.php index 62df7d28..e4456d63 100644 --- a/serendipity_event_multilingual/lang_bg.inc.php +++ b/serendipity_event_multilingual/lang_bg.inc.php @@ -1,4 +1,4 @@ -}}As the blogs Admin, better set the "Global Configuration" Blog language and the "Personal Preferences" language to the same language. Further on, do not use the sidebars language selection in the frontend. Elsewise the language cookie set, can lead to unwanted language problems overall.
+