phpBB

Development Wiki

Deutsch:Coding guidelines

From phpBB Development Wiki

Dies ist der Beginn der Übersetzung der Coding Guidelines der Version 1.22

Coding Guidelines

1. Vorgaben/Voreinstellungen

Deutsch:Coding_guidelines-Vorgaben

Code Layout/Guidelines

Deutsch:Coding_guidelines/code_layout

Styling

Allgemeine Dinge

Templates sollten in einer übereinstimmenden Weise erstellt werden. Sie sollten auf einer Kopie einer bereits existierenden Seite basieren, Beispielsweise index, viewforum oder viewtopic (diese Kombination hat ein breites Spektrum an Bedingungen und Variablen). Bitte beachten Sie das die Einrückungen und Coding Guidelines genauso auf Templates angewendet werden sollen wo es möglich ist.

Die äußere Tabellenklasse forumline wurde durch tablebg ersetzt.

Wenn der <table>-Tag verwendet wird, sorgt die Reihenfolge <table class="" cellspacing="" cellpadding="" border="" align=""> für Konsistenz und erlaubt allen einfach zu erkennen wie die Tabelle aussieht. Das gleiche gilt für die meisten anderen Tags wo optionale Parameter benutzt werden können, Konsistenz ist das Hauptziel.

Jedes Block-Element sollte mit einem TAB eingerückt werden, das gleiche gilt für Tabellen-Elemente wie zum Beispiel <tr><td> usw., wobei der <table>- und <tr>-Tag gleich weit eingerückt sein sollten. Das gilt natürlich nicht für <div>-Tags. Benutzen sie <span> so selten wie möglich… die CSS Definitionen wie beispielsweise Textgröße sind abhängig von der Eltern-Klasse. So bewirkt die Zeile <span class="gensmall"><span class="gensmall">TEST</span></span> sehr, sehr kleine Schrift. Verwenden sie keine span wenn ein anderes Element die Klassen-Definition bekommen kann, Bsp.

<td><span class="gensmall">TEST</span></td>

kann auch einfach folgendermaßen geschrieben werden:

<td class="gensmall">TEST</td>

Versuchen Sie die gleiche Klassen zu verwenden wie in den existierenden Dateien, verwenden Sie beispielsweise kein nav wenn viewtopic gensmall verwendet.

Zeilenfarben und –klassen werden nun vom Template definiert, verwenden Sie IF_S_ROW_COUNT wie es in viewtopic und viewforum zu sehen ist.

Denken Sie daran das die Anordnung von Block-Elementen wichtig ist… trotz das nicht alle Seiten als XHTML 1.0 validiert werden können, versuchen wir dies noch zu erreichen.

Benutzen Sie, wie im Standard auch, cellpadding 2 und cellspacing 0 bei äußeren Tabellen. Innere Tabellen können von 0 bis 3 variiert werden, selbst 4 ist möglich wenn es nötig ist.

Benutzen Sie div Container/CSS für Styling und table für Daten Repräsentation.

Die separaten catXXXX und thXXX Klassen sind weg. Wenn sie ein Feld des Kopfbereiches definieren benutzen Sie einfach <th> anstelle von <th class="thHead">, etc. Das gleiche gilt für cat, benutzen sie <td class="cat"> anstelle von <td class="catLeft"> etc.

Versuchen Sie die Konsistenz vom Standard-Layout und dem benutzen der CSS-Klassen zu bewahren, als Beispiel _EXPLAIN sollte immer unterhalb des Titels stehen, den es erklärt, ein typisches Beispiel hierfür wäre {L_POST_USERNAME}<br /><span class="gensmall">{L_POST_USERNAME_EXPLAIN}</span>... es kann natürlich Ausnahmen geben.

Versuchen Sie die Template-Bedingungen und anderen Anweisungen gleichweit einzurücken wie den Block den es betrifft.

Das ist richtig

<!-- BEGIN test -->
    <
tr>
        <
td>{test.TEXT}</td>
    </
tr>
<!-- 
END test -->

Das ist genauso richtig

<!-- BEGIN test -->
<
tr>
    <
td>{test.TEXT}</td>
</
tr>
<!-- 
END test -->

so können Sie sofort erkennen was genau in einer Schleife ist - hier entscheidet die Lesbarkeit des Codes.

Templates

Benennen von Dateien:

Zuerst: Templates haben jetzt das Suffix ".html" anstelle von ".tpl". Das wurde einfach gemacht um das Leben mancher Leute mit Syntax-Highlighting zu erleichtern, usw.

Variablen:

Alle Template Variablen sollten passend benannt werden (mit Unterstrichen für Leerzeichen), Spracheinträge sollte ein L_, Systemdaten ein S_, URL's ein U_, JavaScript-URL's ein UA_ und JavaScript-Spracheinträgen ein LA_ vorangestellt werden, für den Rest gilt 'wie es halt heißt'.

L_* Template Variablen werden automatisch durch die entsprechenden Spracheinträge ersetzt, wenn der Code keine Zuweisung (und damit überschreibt) macht. Als Beispiel {L_USERNAME} wird durch $user->lang['USERNAME'] ersetzt. Die LA_* Template Variablen werden in der gleichen Weise gehandhabt, jedoch escaped um in den JavaScript Code zu passen. Das sollte den Aufwand für das Laden neuer Sprachvariablen durch Mods reduzieren.

Blöcke und Schleifen:

Die Standardblöcke der Schleifen bleiben und sehen folgendermaßen aus:

<!-- BEGIN loopname -->
    
markup, {loopname.X_YYYYY}, etc.
<!-- 
END loopname -->

Fortgeschrittene Schleifen werden später erklärt. Um Sie nicht zu irritieren: Bedingungen werden dort genauso erklärt, wie weitere Anweisungen.

Dateien einfügen:

Etwas das in 2.0.x existierte, aber nun in 3.0.x nicht mehr existiert, ist die Möglichkeit ein Template einer Variablen zuzuweseisen. Dies wurde benutzt (zum Beispiel) um die jumpbox auszugeben. Stattdessen (vielleicht besser, vielleicht nicht, auf jeden Fall aber flexibler) existiert nun INCLUDE. Das sieht einfach so aus:

<!-- INCLUDE filename -->

Sie werden sicher bemerken das die Hauptseiten mit <!-- INCLUDE overall_header.html --> oder <!-- INCLUDE simple_header.html --> starten, in 2.0.x war im Code definiert welcher Kopf benutzt wurde. In 3.0.x können die Templatedesigner ausgeben was sie wollen. Beachten Sie, dass sie neue Variablen einführen können (beispielsweise andere als im Standard) und benutzen können wie Sie wollen... vielleicht ist dies sinnvoll für ein gemeinsames Menü oder so. Es besteht keine Notwendigkeit mehr so viele Dateien zu verändern wie bei 2.0.x.

PHP:

Eine umstrittene Entscheidung war die Möglichkeit PHP im Template einzufügen. Dies wird ermöglicht indem man den PHPCode in die relevanten Tags einfügt:
<!-- PHP -->
    echo 
"hello!";
<!-- 
ENDPHP -->

Sie können genauso PHP durch externe Dateien einfügen:

<!-- INCLUDEPHP somefile.php -->

dies wird dann vor Ort eingefügt und ausgeführt.

Hinweis: Template Designer sollten auf diese Möglichkeit verzichten. Die Möglichkeit PHP Code einzufügen, existiert hauptsächlich um Banner Code und ähnliches einzufügen, ohne viele Dateien bearbeiten zu müssen (wie in 2.0.x). Es ist nicht für den generellen Gebrauch gedacht... daher wird auf www.phpbb.com kein Template verfügbar gemacht, das PHP benutzt. Außerdem wird PHP in Templates standardmäßig deaktiviert sein (der Administrator wird PHP speziell für Templates aktivieren müssen).

Bedingungen und Kontrollstrukturen:

Die signifikanteste Erweiterung in 3.0.x sind die Bedingungen oder Kontrollstrukturen, "wenn etwas dann mache dies sonst mache jenes". Dieses System ist dem von Smarty sehr ähnlich. Dies mag einige Leute zuerst verwirren, aber es hat ein großes Potential und viel Flexibilität mit nur wenig Vorstellungskraft. In der einfachsten Form sieht ein Konstrukt so aus:

<!-- IF bedingung -->
    
mache
<!-- ENDIF -->

die Bedingung kann viele Formen annehmen, zum Beispiel:

<!-- IF loop.S_ROW_COUNT is even -->
    
mache
<!-- ENDIF -->

Dies wird das mache ausgeben wenn die S_ROW_COUNT Variable in der aktuellen Iteration der Schleife gerade ist (die Anweisung ist TRUE). Sie können verschiedene Vergleiche machen (Standardvergleiche genauso wie äquivalente textuelle Versionen in den eckigen Klammern), eingeschlossen (not, or, and, eq, neq, is sollten benutzt werden wenn die Lesbarkeit gesteigert wird):

== [eq]
!= [
neqne]
<> (
das gleiche wie !=)
!== (
nicht gleich im Typ oder Wert)
=== (
gleich im Typ und Wert)
> [
gt]
< [
lt]
>= [
gte]
<= [
lte]
&& [and]
|| [or]
% [
mod]
! [
not]
+
-
*
/
,
<< (
bitweise shift nacht links)
>> (
bitweise shift nach rechts)
| (
bitweise or)
^ (
bitweise xor)
& (
bitweise and)
~ (
bitweise not)
is (can benutzt werden um Vergleiche zu verbinden)

Standard Paranthesen können genauso genutzt werden um die guten alten BODMAS Regeln geltend zu machen. Zusätzlich sind einige Standard Vergleiche definiert:

even
odd
div

Neben diesen einfachen Verwendungen von IF können sie auch Sequenzen von Vergleichen benutzen wie im folgendem Beispiel:

<!-- IF bedingung1 -->
    
mache
<!-- ELSEIF bedingung2 -->
    
mache
    
.
    .
    .
<!-- ELSEIF 
bedingungN -->
    
mache
<!-- ELSE -->
    
mache
<!-- ENDIF -->

Jede Bedingung wird geprüft und die relevanten Daten ausgegeben wenn eine Bedingung erfüllt wird. Es ist nicht nötig immer ELSEIF zu verwenden, ELSE kan benutzt werden um alles andere abzudecken.

Also was können Sie alles damit machen? Also nehmen wir das Beispiel das die Farbgebung in viewforum. In 2.0.x waren die Zeilenfarben im Code als row color1, row color2 oder row class1, row class2 angegeben. In 3.0.x ist das in das Template verschoben. es sieht vermutlich erst ein wenig abschreckend aus, aber erinnern Sie sich an den Kontrollfluss von oben nach unten, und es nicht nicht mehr so schwer:

<table>
    <!-- IF 
loop.S_ROW_COUNT is even -->
        <
tr class="row1">
    <!-- ELSE -->
        <
tr class="row2">
    <!-- ENDIF -->
    <
td>HELLO!</td>
</
tr>
</
table>

Dies wird dazu führen, dass die Ausgabe der Zeilenfelder die Klasse row1 verwendet wenn die Zeilenzahl gerade ist, und row2 im anderen Fall. Der S_ROW_COUNT Parameter wird automatisch bei Schleifen angelegt. Ein weiteres Beispiel ist folgendes:

<table>
    <!-- IF 
loop.S_ROW_COUNT 10 -->
        <
tr bgcolor="#FF0000">
    <!-- ELSEIF 
loop.S_ROW_COUNT -->
        <
tr bgcolor="#00FF00">
    <!-- ELSEIF 
loop.S_ROW_COUNT -->
        <
tr bgcolor="#0000FF">
    <!-- ELSE -->
        <
tr bgcolor="#FF00FF">
    <!-- ENDIF -->
    <
td>hello!</td>
</
tr>
</
table>

Dies wird die Zeilenfelder in den ersten beiden Reihen lila, blau in den Zeilen 2 bis 5, grün in den Zeilen 5 bis 10 und rot für alle weiteren ausgeben. Also, Sie können einen "schönen" Farbverlauf erstellen, als Beispiel.

Was können Sie noch machen? Also, Sie können IF benutzen um allgemeine Überprüfungen zu machen wie dem Login Status eines Users:

<!-- IF S_USER_LOGGED_IN -->
    
mache
<!-- ENDIF -->

Dies ersetzt die existierende (erschummelte) Methode in 2.0.x eines leeren Arrays und BEGIN/END.

Übersetzungsrichtlinien (i18n/L10n)

Standardisierung

Grund:

phpBB ist einer der am meisten übersetzten Open-Source Projekten, mit über 60 Lokalisierungen in der aktuellen, stable Version. Trotz das die aus dem Stegreif entstandene Methode für die Benennung der Sprachpakete funktionierte, hoffen wir diesen Prozess für phpBB3 und nachfolgende Versionen durchdachter zu gestalten, um eine bessere Unterstützung für aktuelle und zukünftige WebBrowser zu bieten.

Encoding:

Mit phpBB3 wird die Ausgabe Encodierung für das Forum auf UTF-8, einem universellem Zeichensatz vom Unicode Consortium, umgestellt, welches eine Zusammenfassung aus US-ASCII und ISO-8859-1 ist. Durch die Verwendung dieses Zeichensatzes wird ermöglicht Scripts auszuführen, die früher verschiedene Zeichensätze benötigten (beispielsweise ISO-8859-1 bis ISO-8859-15 (Latein, Griechisch, kyrillisch, thailändisch, hebräisch, arabisch); GB2312 (vereinfachtes Chinesisch); Big5 (Traditionelles Chinesisch), EUC-JP (Japanisch), EUC-KR (koreanisch), VISCII (vietnamesisch); und weitere). Dadurch entfällt das konvertieren zwischen den verschiedenen Zeichensätzen und verbessert die Zugänglichkeit für mehrsprachige Foren.

Deshalb müssen die Sprachdateien für phpBB jetzt als UTF-8 Dokumente gespeichert werden, mit dem Vorbehalt das die Dateien kein BOM enthalten dürfen, aufgrund der nicht-Unicode-fähigen PHP Versionen. Für Foren mit dem Lateinischem Zeichensatz (gilt für fast alle europäischen Sprachen), ist diese Änderung am einfachsten, da UTF-8 eine Erweiterung des US-ASCII und ISO-8859-1 ist.

Sprach-Tags:

Die IETF hat kürzlich die RFC 4646 die Tags zur Identifizierung herausgegeben, welche in Kombination mit den RFC 4647 den älteren RFC 3006 und noch älteren RFC 1766 ersetzt. RFC 4646 benutzt ISO 639-1/ISO 639-2, ISO 3166-1 alpha-2, ISO 15924 und UN M.49 um einen Sprach Tag zu definieren. Jeder komplette Tag ist eine Zusammenstellung von Sub-Tags, welche Groß- und Kleinschreibung nicht beachten und leer sein können.

Die Reihenfolge der Sub-Tags wenn alle vorhanden sind ist: Sprache-Schriftsystem-Region-Variante-Erweiterung-private Nutzung. Sollte ein Sub-Tag leer sein, so wird der zugehörige Bindestrich ebenfalls weggelassen. Deshalb wäre der Sprach-Tag für Englisch en und nicht en-----.

Die meisten Sprach-Tags bestehen aus zwei oder drei Zeichen (von ISO 639-1/ISO 639-2). Manchmal folgt diesem eine zwei- bis dreistellige Zahl als Regions-Sub-Tag (von ISO 3166-1 alpha-2 oder UN M.49). Einige Beispiele sind:

Sprach-Tag Beschreibung Sub-Tag Komponenten
en Englisch Sprache
mas Masai(?) Sprache
fr-CA Französisch wie es in Kanada benutzt wird Sprache+Region
en-833 Englisch wie es auf der "Isle of Man" benutzt wird Sprache+Region
zh-Hans Chinesisch in einfacher Schrift geschrieben Sprache+Schriftsystem
zh-Hant-HK Chinesisch in traditioneller Schrift wie es in Hong Kong benutzt wird Sprache+Schriftsystem+Region
de-AT-1996 Deutsch wie es in Österreich benutzt wird, Rechtschreibung von 1996 Sprache+Region+Variante

Das wichtigste Ziel der Sprach-Tags ist es die kennzeichnenden Informationen zu transportieren, und diese trotzdem so kurz wie möglich zu halten. Als Beispiel wird en, fr und ja als Gegenstück zu en-GB, fr-FR, ja-JP verwendet, weil wir wissen das englisch, französisch und japanisch ihren Ursprung in Großbritannien, Frankreich und Japan haben.

Das nächste ist der ISO 15924 Sprachsystem Code und wann man es verwendet, und wann nicht. Als Beispiel en-Latin ist syntaktisch korrekt um Englisch mit lateinischen Zeichen zu beschreiben, aber in der Welt wird englisch eigentlich fast immer in Lateinischen Buchstaben geschrieben. Für solche Sprachen wie englisch die überwiegend nur mit einem Schriftsystem geschrieben werden, hat die IANA Language Subtag Registry ein "Suppress-Script" (unterdrücken/weglassen) Feld, das bedeutet das der Schriftsystem-Sub-Tag in solchen Fällen weggelassen werden sollte, außer ein spezifisches Schriftsystem benötigt dies. Manche Sprachen werden in mehr als einem Schriftsystem geschrieben und in solchen Fällen wird der Schriftsystem-Sub-Tag bestärkt, da manche Benutzer die Sprache in einem Schriftsystem lesen können, aber nicht in einem anderen. Einige Beispiele sind:

Sprach-Tag Beschreibung Sub-Tag Komponenten
en-Brai englisch in Blindenschrift Sprache+Schriftsystem
en-Dsrt englisch in "Deseret" (Mormonen) Sprache+Schriftsystem
sr-Latn serbisch mit lateinischer Schrift Sprache+Schriftsystem
sr-Cyrl serbisch mit kyrillischen Schriftzeichen Sprache+Schriftsystem
mn-Mong mongolisch in mongolischen Schriftzeichen Sprache+Schriftsystem
mn-Cyrl mongoliisch in kyrillischen Schrifzeichen Sprache+Schriftsystem
mn-Phag mongolisch in "Phags-pa" geschrieben Sprache+Schriftsystem
az-Cyrl-AZ Aserbaidschanisch in kyrillischer Schrift wie sie in Aserbaid benutzt wird Sprache+Schriftsystem+Region
az-Latn-AZ Aserbaidschanisch in lateinischer Schrift wie sie in Aserbaid benutzt wird Sprache+Schriftsystem+Region
az-Arab-IR Aserbaidschanisch in arabischer Schrift wie sie im Iran benutzt wird Sprache+Schriftsystem+Region

Der dreistellige UN M.49 Code over sollte anstelle des zwei-stelligen ISO 3166-1 alpha-2 Code verwendet werden wenn ein makro-geographische Unterscheidung benötigt wird und/oder ISO 3166-1 alpha-2 mehrdeutig ist.

Beispiele für englisch mit makro-geographischen Regionen:

ISO 639-1/ISO 639-2 + ISO 3166-1 alpha-2 ISO 639-1/ISO 639-2 + UN M.49 (Beispielhafte makro Regionen)
en-AU englisch wie es in Australien benutzt wird en-053 englisch wie es in Australien & Neuseeland benutzt wird en-009 englisch wie es in Ozeanien benutzt wird
en-NZ englisch wie es in Neuseeland benutzt wird
en-FJ englisch wie es in Fidschi benutzt wird en-054 englisch wie es in Melanesien benutzt wird

Beispiele mit Spanisch und makro-geographische Regionen:

ISO 639-1/ISO 639-2 + ISO 3166-1 alpha-2 ISO 639-1/ISO 639-2 + UN M.49 (Beispielhafte makro Regionen)
es-PR spanisch wie es in Puerto Rico genutzt wird es-419 spanisch wie es in Latein Amerika & der Karibik genutzt wird es-019 spanisch wie es in Amerika genutzt wird
es-HN spanisch wie es in Honduras genutzt wird
es-AR spanisch wie es in Argentinien genutzt wird
es-US spanisch wie es in der USA genutzt wird es-021 spanisch wie es in Nordamerika genutzt wird

Beispiele bei den ISO 3166-1 alpha-2 mehrdeutig ist und UN M.49 bevorzugt werden sollte:

CS Zuweisung vor 1994 CS Zuweisung nach 1994
CS Tschechoslowakei (ISO 3166-1)
200 Tschechoslowakei (UN M.49)
CS Serbienn & Montenegro (ISO 3166-1)
891 Serbien & Montenegro (UN M.49)
CZ Tschechische Republik (ISO 3166-1)
203 Tschechische Republik (UN M.49)
SK Slowakei (ISO 3166-1)
703 Slowakei (UN M.49)
RS Serbien (ISO 3166-1)
688 Serbien (UN M.49)
ME Montenegro (ISO 3166-1)
499 Montenegro (UN M.49)

Makro-Sprachen & örtliche Prägungen:

RFC 4646 vorausschauende Features welche in ISO 639-3 verfügbar gemacht werden sollen (derzeit nur Entwurf), zielen darauf ab eine so vollständige Auflistung der Sprachen verfügbar zu machen, einschließlich lebender, toter, altertümlicher und konstruierter Sprachen, egal ob Haupt-, Neben- oder ungeschriebener Sprache. Ein neues Feature von ISO 639-3 verglichen zu den zwei Vorgängern ist das Konzept der Makrosprachen, arabisch und chinesisch sind hierfür zwei Beispiele. In solchen Fällen ist der jeweilige Code von ar und zh sehr vage bei den Dialekten/Prägungen oder vielleicht zu knapp und damit zu schwer für alle außer den besonders gebildeten Benutzern. Für solche Makro-Sprachen wird empfohlen das der Sprach-Sub-Tag als Suffix für das Makro-Sprach-Tag genutzt wird, Beispiel:

Sprach-Tag Beschreibung Sub-Tags Komponenten
zh-cmn Mandarin ("Putonghau"/"Guoyu") chinesisch Makro-Sprache+Prägung
zh-yue "Yue" (kantonesisch) chinesisch Makro-Sprache+Prägung
zh-cmn-Hans Mandarin ("Putonghau"/"Guoyu") chinesisch in vereinfachter Schrift Makro-Sprache+Prägung+Schriftsystem
zh-cmn-Hant Mandarin ("Putonghau"/"Guoyu") chinesisch in traditioneller Schrift Makro-Sprache+Prägung+Schriftsystem
zh-nan-Latn-TW Minnan ("Hoklo") chinesisch in lateinischer Schrift ("POJ Romanisation") wie es in Taiwan genutzt wird Makro-Sprache+Prägung+Schriftsystem+Region

Weitere Erwägungen

Normalisierung der Sprach-Tags für phpBB:

Für phpBB werden die Sprach-Tags nicht in ihrer Originalform benutzt, sondern kleingeschrieben und der Bindestrich - wird wenn es angemessen ist durch den Unterstrich _ ersetzt, hier ein paar Beispiele:

Original Sprach Tag Beschreibung Wert der USER_LANG in ./common.php Sprachpaketname im Verzeichnis /language/
en britisches Englisch en en
de-AT Deutsch wie es in Österreich benutzt wird de-at de_at
es-419 Spanisch wie es in Latein Amerika & der Karibik verwendet wird en-419 en_419
zh-yue-Hant-HK kantonesisch in traditionellen Schriftzeichen wie es in Hong Kong benutzt wird zh-yue-hant-hk zh_yue_hant_hk

Benutzung der iso.txt:

Die iso.txt Datei ist eine kleine vollständig in UTF-8 kodierte Datei die drei Zeilen enthält:

  • 1. Englischer Name der Sprache
  • 2. Name in der Sprache in eben dieser Sprache
  • 3. Informationen zum Autoren

Die iso.txt wird automatisch beim einstellen auf phpBB.com generiert. Sie brauchen diese Datei also nicht erstellen wenn Sie diese auf phpBB.com veröffentlichen wollen, aber denken Sie daran das phpBB diese Datei benötigt um die Sprache zu erkennen.

Weil die Sprach-Tags selber maschinell gelesen werden, können diese auf Menschen verwirrend wirken und weil die beschreibenden Strings in der iso.txt benötigt werden. Trotz das en-US noch sehr einfach in "Englisch wie es in der USA benutzt wird" aufgelöst werden kann, ist de-CH schon schwieriger, weniger Menschen wissen das das de von "Deutsch" kommt, German für "German" und CH die offizielle Abkürzung für die Schweiz oder auch die "Confoederatio Helvetica" ist.

Für jede englische Beschreibung kommt der Sprachname zuerst und dann zusätzliche Informationen zur Beschreibung der Sub-Tags des Sprach Codes hintereinander aufgelistet, mit Kommas getrennt in Klammern, Beispiel:

Original Sprach-Tag Englische Beschreibung in der iso.txt
en British English
en-US English (United States)
en-053 English (Australia & New Zealand)
de German
de-CH-1996 German (Switzerland, 1996 orthography)
gws-1996 Swiss German (1996 orthography)
zh-cmn-Hans-CN Mandarin Chinese (Simplified, Mainland China)
zh-yue-Hant-HK Cantonese Chinese (Traditional, Hong Kong)

Für die übersetzte Sprachbeschreibung, übersetzen Sie einfach die englische Version, und benutzen Sie was für die Zeichensetzung in der Sprache benutzt wird, vorausgesetzt die Sprache besitzt überhaupt eine Zeichensetzung.

Überlegen zu bidirektionalem Unicode:

Da phpBB jetzt UTF-8 verwendet, müssen alle Übersetzer nun in Kauf nehmen das bestimmte Strings in der umgekehrten Direktionalität angezeigt wird, oder die Ausgabe ungewiss ist.

Die verschiedenen Unicode Kontrollzeichen für bidirektionalen Text und ihre HTML Äquivalente wenn entsprechend sind die folgenden:

Unicode Zeichen Abkürzung Unicode Code-Punkt Unicodezeichen Name HTML äquivalente Zeichen/Entities
LRM U+200E Left-to-Right Mark (links-nach-rechts Kennzeichnung)
RLM U+200F Right-to-Left Mark (recht-nach-links Kennzeichnung)
LRE U+202A Left-to-Right Embedding (links-nach-rechts Einschub) dir="ltr"
RLE U+202B Right-to-Left Embedding (rechts-nach-links Einschub) dir="rtl"
PDF U+202C Pop Directional Formatting </bdo>
LRO U+202D Left-to-Right Override (links-nach-rechts überschreiben)
RLO U+202E Right-to-Left Override (rechts-nach-links überschreiben)

In der iso.txt kann Textrichtung explizit mit den Unicode Zeichen werden, die 3 Methoden bieten links-nach-rechts/rechts-nach-links Kennzeichnungen/Einschübe/überschreibungen, ohne sie wird die Anordnung der Zeichen falsch, beispielsweise:

Direktionalität Unbearbeitete Zeichenfolge Anzeigen der lokalisierten Beschreibung der iso.txt Anordnung
dir="ltr" English (Australia & New Zealand) English (Australia & New Zealand) Korrekt
dir="rtl" English (Australia & New Zealand) (English (Australia & New Zealand Inkorrekt
dir="rtl" mit LRM English (Australia & New Zealand)U+200E English (Australia & New Zealand)‎ Korrekt
dir="rtl" mit LRE & PDF U+202AEnglish (Australia & New Zealand)U+202C ‪English (Australia & New Zealand)‬ Korrekt
dir="rtl" mit LRO & PDF U+202DEnglish (Australia & New Zealand)U+202C ‭English (Australia & New Zealand) Korrekt

Bei der Wahl der drei Methoden wird es meist LRM oder RLM sein, um ein "starkes" Zeichen welches die die eindeutigen Punktierungszeichen vollständig umspannt und daher die korrekte Direktionalität ausreichend vererbt.

In einigen Fällen kann das Script links-nach-rechts und rechts-nach-links Direktionalitäten mischen, da kann LRE & RLE mit PDF besser passen. Zum Schluss, in sehr seltenen Fällen wo die Direktionalität erzwungen werden muss, benutzen Sie LRO & RLO mit PDF.

Für weitere Informationen bei den Techniken der Bidirektionalität, schauen Sie bitte in das W3C Tutorial zu den Techniken bei XHTML Seiten mit bidirektionalem Text (englisch).

Arbeiten mit Platzhaltern:

Da phpBB in mehrere Sprachen mit unterschiedlichen Textrichtungen als deutsch arbeitet, ist es möglich das bestimmte Werte in einer anderen Reihenfolge kommen. Nehmen Sie das simple "Seite X von Y" als Beispiel, in deutsch kann dies einfach folgendermaßen geschrieben werden:

...
'PAGE_OF'    =>    'Seite %s von %s',
        
/* Einfach die Werte schnappen und einsetzen und
        hoffen das sie in der richtigen Reihenfolge kommen */
    
...

… ein besserer Weg um explizit die Reihenfolge bei dem Ersetzen festzulegen ist:

...
'PAGE_OF'    =>    'Seite %1$s von %2$s',
        
/* Explizite Reihenfolge der Ersetzungen,
        selbst wenn sie in der gleichen Reihenfolge wie in deutsch sind */
    
...

Warum damit herumschlagen? Weil manche Sprachen das zurück in das Deutsche übersetzt sowas geschrieben haben könnten wie:

...
'PAGE_OF'    =>    'Gesamt %2$s Seiten, gerade auf Seite %1$s',
        
/* Explizite Reihenfolge der Ersetzungen, zurückübersetzt verglichen
        mit dem deutschen zeigt das die Gesamtzahl der Seiten zuerst kommt */
    
...

Schreibstil

Verschiedene Tipps und Kniffe:

Da die Sprachdateien PHP-Dateien sind, indem die verschiedenen Strings für phpBB als Array gespeichert werden, welche wiederum für das Anzeigen auf der HTML Seite genutzt werden, sind Syntax-Regeln nötig. Potentielle Problem Zeichen sind: ' (gerades Apostroph), " (Anführungszeichen), < (kleiner-als Zeichen), > (größer-als Zeichen) und & (kaufmännisches Und).

// Schlecht - Das nicht maskiert Apostroph wird einen PHP parse Fehler hervorrufen

...
'CONV_ERROR_NO_AVATAR_PATH'
    
=>    'Note to developer: you must specify $convertor['avatar_path'] to use %s.',
    ...

// Gut - Apostrophe sollten mit dem Backslash maskiert werden, beispielsweise mit: \

...
'CONV_ERROR_NO_AVATAR_PATH'
    
=>    'Note to developer: you must specify $convertor[\'avatar_path\'] to use %s.',
    ...

Wie auch immer, da phpBB3 jetzt UTF-8 als Kodierung nutzt, können wir das zu unserem Vorteil nutzen und müssen nicht mehr daran denken das Apostroph zu maskieren:

// Schlecht - Das nicht maskiert Apostroph wird einen PHP parse Fehler hervorrufen

...
'USE_PERMISSIONS'    =>    'Test out user's permissions',
    ...

// Okay - nicht-Programmierer würden "user\'s" nicht automatisch benutzen

...
'USE_PERMISSIONS'    =>    'Test out user\'s permissions',
    ...

// Am besten - Benutzten Sie das rechtsliegende Apostroph

...
'USE_PERMISSIONS'    =>    'Test out user’s permissions',
    ...

Das " (Anführungszeichen), < (kleiner-als Zeichen) und > (größer als Zeichen) Zeichen können alle als Bildzeichen oder als HTML Entity angezeigt werden, als Beispiel:

// Schlecht - Kein gültiges HTML, da Segmente die nicht Teil eines Tags sind nicht als Entity geschrieben sind

...
'FOO_BAR'    =>    'PHP version < 4.3.3.<br />
    Visit "Downloads" at <a href="http://www.php.net/">www.php.net</a>.'
,
    ...

// Okay - Kein ungültiges HTML mehr, aber $quot;$amp;quot;$quot; ist sehr unschön

...
'FOO_BAR'    =>    'PHP version &lt; 4.3.3.<br />
    Visit &quot;Downloads&quot; at <a href="http://www.php.net/">www.php.net</a>.'
,
    ...

// Am besten - kein ungültiges HTML und die Benutzung typographisch-korrekter Anführungszeichen

...
'FOO_BAR'    =>    'PHP version &lt; 4.3.3.<br />
    Visit “Downloads” at <a href="http://www.php.net/">www.php.net</a>.'
,
    ...

Zum Schluss: das & (kaufmännische Und) muss immer als Entity geschrieben werden, unabhängig davon wo es benutzt wird:

// Schlecht - kein gültiges HTML, keines der &'s ist als Entity geschrieben

...
'FOO_BAR'    =>    '<a href="http://somedomain.tld/?foo=1&bar=2">Foo & Bar</a>.',
    ...

// Gut - Gültiges HTML, das & ist in allen Fällen als Entity geschrieben

...
'FOO_BAR'    =>    '<a href="http://somedomain.tld/?foo=1&amp;bar=2">Foo &amp; Bar</a>.',
    ...

Um zu erfahren wie diese Zeichen eingegeben werden lesen sie bitte http://en.wikipedia.org/wiki/Unicode#Input_methods da dies sehr stark vom Betriebssystem, der aktuellen Tastatursprache und den nativen Fähigkeiten des Editors zum bearbeiten der phpBB Sprachdateien abhängt.

Rechtschreibung, Punktierung, Grammatik und ähnliches:

Die Standardsprache mit der phpBB ausgeliefert wird ist britisches Englisch, welches die Rechtschreibung der Cambridge University Press verwendet und dem Sprachcode en zugeordnet ist. Der Schreibstil tendieren zu dem formalen und Übersetzungen sollten versuchen dies nachzuahmen. Zumindest die Varianten mit den kompaktesten Sprachcodes. Weniger formale Übersetzungen oder die mit Umgangssprache müssen als solche gekennzeichnet werden, entweder mit der Erweiterung oder dem private Nutzung Sprachcode.

7. Guidelines Changelog

Deutsch:Coding_guidelines/Changelog