1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606
|
<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: 22755 -->
<sect1 id="zend.locale.introduction">
<title>Einführung</title>
<para>
<classname>Zend_Locale</classname> ist die Antwort des Frameworks auf die Frage "Wie kann
dieselbe Anwendung auf der ganzen Welt verwendet werden?". Die meisten Leute werden sagen
"Das ist einfach. Lasst uns alle Ausgaben in die unterschiedlichsten Sprachen übersetzen".
Aber eine einfache Übersetzungstabelle, die Phrasen von einer Sprache in die andere
übersetzt, ist nicht genug. Verschiedene Regionen haben auch unterschiedliche Regeln für
Vornamen, Nachnamen, Titel, Format von Nummern, Daten, Zeiten, Währungen usw.
</para>
<para>
Was wir benötigen ist <ulink
url="http://en.wikipedia.org/wiki/Internationalization_and_localization">Lokalisierung
und die vergleichbare Internationalisierung</ulink>. Beide werden oft abgekürzt zu
<emphasis>L10n</emphasis> und <emphasis>I18n</emphasis>. Internationalisierung bezeichnet
mehr die Benutzung von Systemen für die spezielle Benutzung durch eindeutige Gruppen wie zum
Beispiel Sprachübersetzung, Unterstützung von lokalen Konventionen für Plurale, Daten,
Zeiten, Währungen, Namen, Symbolen, Sortierungen, Reihungen und viele mehr.
<emphasis>L10n</emphasis> und <emphasis>I18n</emphasis> sind einander sehr ähnlich. Zend
Framework bietet Unterstützung für diese Konventionen durch eine Kombination von Komponenten
wie <classname>Zend_Locale</classname>, <classname>Zend_Date</classname>,
<classname>Zend_Measure</classname>, <classname>Zend_Translate</classname>,
<classname>Zend_Currency</classname> und <classname>Zend_TimeSync</classname>.
</para>
<tip>
<title>Zend_Locale und setLocale()</title>
<para>
Die <ulink url="http://php.net/setlocale">Dokumentation von PHP</ulink> sagt, dass
<methodname>setlocale()</methodname> nicht threadsicher ist, weil es pro Prozess
behandelt wird und nicht pro Thread. Das bedeutet, dass man in multithreaded Umgebungen
das Problem bekommen kann, dass sich das Gebietsschema (Locale) ändert, während das Skript
diese Änderung nie selbst durchgeführt hat. Deswegen kann es zu unerwarteten Ergebnissen
kommen, wenn man <methodname>setLocale()</methodname> in seinen Skripts verwendet.
</para>
<para>
Wenn <classname>Zend_Locale</classname> verwendet wird, hat man diese Einschränkungen
nicht, da <classname>Zend_Locale</classname> weder von <acronym>PHP</acronym>s
<methodname>setlocale()</methodname> abhängig ist, noch irgendwie mit ihr gekoppelt ist.
</para>
</tip>
<sect2 id="zend.locale.whatislocalization">
<title>Was ist Lokalisierung</title>
<para>
Lokalisierung bedeutet, dass eine Anwendung (oder Homepage) von verschiedenen Benutzern
verwendet werden kann, die unterschiedliche Sprachen sprechen. Aber wie bereits
angedeutet, heißt Lokalisierung mehr als nur die Übersetzung von Zeichenketten. Es
beinhaltet
</para>
<itemizedlist mark='opencircle'>
<listitem>
<para>
<classname>Zend_Locale</classname> - Unterstützung für Gebietsschemata, welche
Unterstützung für Lokalisierungen von anderen Zend Framework Komponenten
bieten.
</para>
</listitem>
<listitem>
<para>
<classname>Zend_Translate</classname> - Übersetzung von Zeichenketten.
</para>
</listitem>
<listitem>
<para>
<classname>Zend_Date</classname> - Lokalisierung von Daten und Zeiten.
</para>
</listitem>
<listitem>
<para>
<classname>Zend_Calendar</classname> - Lokalisierung von Kalendern
(Unterstützung für nicht Gregorianische Kalendersysteme)
</para>
</listitem>
<listitem>
<para>
<classname>Zend_Currency</classname> - Lokalisierung von Währungen.
</para>
</listitem>
<listitem>
<para>
<classname>Zend_Locale_Format</classname> - Erkennen und erzeugen von
lokalisierten Zahlen.
</para>
</listitem>
<listitem>
<para>
<classname>Zend_Locale_Data</classname> - Empfangen von lokalisierten
Standard-Übersetzungen für Länder, Sprachen und <ulink
url="http://unicode.org/cldr/">mehr aus der <acronym>CLDR</acronym></ulink>.
</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="zend.locale.whatis">
<title>Was ist ein Gebietsschema?</title>
<para>
Jeder Computer benutzt Gebietsschemata, selbst wenn Sie es nicht wissen. Anwendungen,
welche keine Unterstützung für Lokalisierung bieten, unterstützen zumindest genau ein
Gebietsschema (das Gebietsschema des Authors). Wenn eine Klasse oder Funktion
Lokalisierung verwendet, sagen wir, sie ist <emphasis>lokalisierbar</emphasis>. Aber wie
weiß der Code, welches Gebietsschema ein Benutzer erwartet ?
</para>
<para>
Eine Gebietsschema Zeichenkette oder Objekt, welches ein unterstütztes Gebietsschema
identifiziert, gibt <classname>Zend_Locale</classname> und dessen Unterklassen Zugriff
auf Informationen über die Sprache und Region, welche der Benutzer erwartet.
Formatierungen, Normalisierungen und Konvertierungen werden anhand dieser Informationen
durchgeführt.
</para>
</sect2>
<sect2 id="zend.locale.representation">
<title>Wodurch werden Gebietsschemata repräsentiert?</title>
<para>
Eine Gebietsschema-Zeichenkette besteht aus Informationen über die Sprache des Benutzers
und die bevorzugte/primäre geographische Region (z.B. Staat oder Region von seinem
Zuhause oder Arbeitsplatz). Die Gebietsschema Zeichenkette, welche im Zend Framework
benutzt werden, sind international definierte Standardabkürzungen von Sprachen und
Regionen. Sie werden geschrieben als <emphasis>sprache_REGION</emphasis>. Beide Teile,
sowohl Sprache als auch Region, werden mit Buchstaben, <acronym>ASCII</acronym>-Zeichen,
abgekürzt.
</para>
<note>
<para>
Man muß darauf achten, dass nicht nur Gebietsschemata mit 2 Zeichen existieren, wie die
meisten Leute denken. Es gibt auch Sprachen und Regionen, die nicht nur mit 2 Zeichen
abgekürzt werden. Deswegen sollte man die Region und Sprache NICHT selbst trennen,
sondern <classname>Zend_Locale</classname> verwenden, um die Sprache oder Region von
einem Gebietsschema-String zu trennen. Andernfalls kann es zu unerwartetem Verhalten
im eigenen Code kommen, wenn man versucht, das selbst zu machen.
</para>
</note>
<para>
Ein Benutzer aus den USA würde die Sprache Englisch und die Region
<constant>USA</constant> erwarten, beschrieben durch das Gebietsschema "en_US". Ein
Benutzer aus Deutschland würde die Sprache Deutsch und die Region
Deutschland erwarten, beschrieben durch das Gebietsschema "de_DE". Hier
findest Du eine <ulink
url="http://unicode.org/cldr/data/diff/supplemental/languages_and_territories.html">Liste
von vordefinierten Sprachen und Kombinationen von Regionen</ulink> wenn ein
bestimmtes Gebietsschema im Zend Framework ausgewählt werden muß.
</para>
<example id="zend.locale.representation.example-1">
<title>Auswählen eines speziellen Gebietsschemas</title>
<programlisting language="php"><![CDATA[
$locale = new Zend_Locale('de_DE'); // deutsche Sprache _ Deutschland
]]></programlisting>
</example>
<para>
Ein deutscher Benutzer in Amerika würde die Sprache Deutsch und die Region
<constant>USA</constant> erwarten, aber diese nicht-standardmäßigen Mischungen werden
nicht direkt als "Gebietsschema" unterstützt und erkannt. Wird eine ungültige
Kombination benutzt, dann wird sie stattdessen automatisch gekürzt, indem die Region
entfernt wird. Zum Beispiel würde "de_IS" zu "de" und "xh_RU" zu "xh"
gekürzt werden, weil keine dieser Kombinationen gültig ist. Wenn die Sprache nicht
unterstützt wird (z.B. "zz_US") oder diese nicht existiert, dann wird zusätzlich ein
Standard "root" Gebietsschema benutzt. Dieses "root" Gebietsschema hat
Standarddefinitionen für international bekannte Repräsentationen von Daten, Zeiten,
Nummern, Währungen usw. Der Prozess der Kürzung hängt von der gewünschten Information
ab, weil einige Kombinationen von Sprache und Region für eine gewisse Art von
Informationen gültig sind (z.B. Daten) aber für andere nicht (z.B. Währungsformate).
</para>
<para>
Achtung vor historischen Änderungen oder dem Versuch, die verschiedenen Änderungen der
Zeitzonen zu verfolgen, die im Laufe der langen Zeit in den vielen Regionen gemacht
wurden, da Zend Framework Komponenten darüber nichts wissen kann. Zum Beispiel kann <ulink
url="http://www.statoids.com/tus.html">hier eine historische Liste</ulink> mit
Dutzenden Änderungen von Regierungen angesehen werden und ob eine Region
<acronym>DST</acronym> (Sommer-/Winterzeit) unterstützt und sogar in welche Zeitzone
eine bestimmte geographische Region gehört. Das bedeutet, wenn Datumsberechnungen
gemacht werden, wird die Berechnung, welche durch die Zend Framework Komponenten
durchgeführt wird, nicht an diese Änderungen angepasst. Stattdessen wird die korrekte
Uhrzeit benutzt, welche für die aktuell benutzte Zeitzone angegeben wurde, wobei moderne
Regeln für Sommer-/Winterzeit und Zeitzonenzuordnung anhand von geographischen Regionen
verwendet werden.
</para>
</sect2>
<sect2 id="zend.locale.selection">
<title>Auswahl des richtigen Gebietsschemas</title>
<para>
In den meisten Situationen wird <command>new Zend_Locale()</command> automatisch das
richtige Gebietsschema auswählen, wobei die Informationen benutzt werden, welche der
Webbrowser des Benutzers zur Verfügung stellt. Wenn statt dessen
<command>new Zend_Locale(Zend_Locale::ENVIRONMENT</command> benutzt wird, dann werden
die Informationen vom Betriebsystem des hostenden Servers, dafür verwendet,
wie anbei beschrieben.
</para>
<example id="zend.locale.selection.example-1">
<title>Automatische Auswahl des Gebietsschemas</title>
<programlisting language="php"><![CDATA[
$locale = new Zend_Locale();
// Standard verhalten, wie eine Zeile weiter oben
$locale1 = new Zend_Locale(Zend_Locale::BROWSER);
// Bevorzuge die Einstellungen des hostenden Servers
$locale2 = new Zend_Locale(Zend_Locale::ENVIRONMENT);
// Bevorzuge die Einstellungen der Framework Anwendung
$locale3 = new Zend_Locale(Zend_Locale::FRAMEWORK);
]]></programlisting>
</example>
<para>
Der Suchalgorithmus, welcher von <classname>Zend_Locale</classname> für die automatische
Auswahl des Gebietsschemas verwendet wird, verwendet drei Informationsquellen:
<orderedlist>
<listitem>
<para>
const <constant>Zend_Locale::BROWSER</constant> - Der Webbrowser des
Benutzers, welcher die Informationen mit jeder Anfrage schickt. Diese wird
von <acronym>PHP</acronym> durch die globale Variable
<constant>$_SERVER['HTTP_ACCEPT_LANGUAGE']</constant> veröffentlicht. Wenn
kein passendes Gebietsschema gefunden wurde, dann wird mit
<constant>ENVIRONMENT</constant> gesucht und als letztes mit
<constant>FRAMEWORK</constant> gesucht.
</para>
</listitem>
<listitem>
<para>
const <constant>Zend_Locale::ENVIRONMENT</constant> -
<acronym>PHP</acronym> veröffentlicht das Gebietsschema des hostenden
Servers über die interne <acronym>PHP</acronym>-Funktion
<methodname>setlocale()</methodname>. Wenn kein passendes Gebietsschema
gefunden wurde, dann wird mit <constant>FRAMEWORK</constant> und als letztes
mit <constant>BROWSER</constant> gesucht.
</para>
</listitem>
<listitem>
<para>
const <constant>Zend_Locale::FRAMEWORK</constant> - Wenn Zend Framework
einen standardisierten Weg zur Verfügung stellt, um für Komponenten
Standardwerte zu definieren (das ist geplant, aber noch nicht realisiert),
dann wird die Verwendung dieser Konstante das Gebietsschema anhand dieser
Standardwerte auswählen. Wenn kein passendes Gebietsschema gefunden wurde,
dann wird mit <constant>ENVIRONMENT</constant> und als letztes mit
<constant>BROWSER</constant> gesucht.
</para>
</listitem>
</orderedlist>
</para>
</sect2>
<sect2 id="zend.locale.selection.automatic">
<title>Verwenden automatischer Gebietsschemata</title>
<para>
<classname>Zend_Locale</classname> bietet drei zusätzliche Gebietsschemata. Diese
Gebietsschemata gehören zu keiner Sprache oder Region. Es sind "automatische"
Gebietsschemata, was bedeutet dass sie den gleichen Effekt haben wie die Methode
<methodname>getDefault()</methodname>, aber ohne die negativen Effekte wie die
Erstellung einer Instanz. Diese "automatischen" Gebietsschemata können überall verwendet
werden, wo auch Standard-Gebietsschemata verwendet werden können, und für die Definition
eines Gebietsschemas, kann auch die String-Repräsentation verwendet werden. Das bietet
Einfachheit für Situationen, wo mit Gebietsschemas gearbeitet wird, die vom Browser
geliefert werden.
</para>
<para>
Es gibt drei Gebietsschemata mit leicht unterschiedlichem Verhalten:
<orderedlist>
<listitem>
<para>
'<property>browser</property>' - <classname>Zend_Locale</classname> soll mit
den Informationen arbeiten, die durch den Web Browser des Benutzers geliefert
werden. Sie werden von <acronym>PHP</acronym> in der globalen Variable
<constant>$_SERVER['HTTP_ACCEPT_LANGUAGE']</constant> veröffentlicht.
</para>
<para>
Wenn ein Benutzer mehr als ein Gebietsschema in seinem Browser anbietet,
wird <classname>Zend_Locale</classname> das erste gefundene Gebietsschema
verwenden. Wenn der Benutzer kein Gebietsschema liefert oder das Skript von
der Kommandozeile aufgerufen wird, wird automatisch das Gebietsschema
'<property>environment</property>' verwendet und zurückgegeben.
</para>
</listitem>
<listitem>
<para>
'<property>environment</property>' - <classname>Zend_Locale</classname> soll
mit den Informationen arbeiten, welche vom Host Server geliefert werden.
Sie werden von <acronym>PHP</acronym> über die interne Funktion
<methodname>setlocale()</methodname> veröffentlicht.
</para>
<para>
Wenn eine Umgebung mehr als ein Gebietsschema anbietet, wird
<classname>Zend_Locale</classname> das erste gefundene Gebietsschema
verwenden. Wenn der Host kein Gebietsschema anbietet, wird automatisch das
Gebietsschema '<property>browser</property>' verwendet und zurückgegeben.
</para>
</listitem>
<listitem>
<para>
'<property>auto</property>' - <classname>Zend_Locale</classname> soll
automatisch jedes beliebige Gebietsschema erkennen mit dem gearbeitet
werden kann. Zuerst wird nach dem Gebietsschema des Benutzers gesucht und
anschließend, wenn das nicht erfolgreich war, nach dem Gebietsschema des
Hosts.
</para>
<para>
Wenn kein Gebietsschema gefunden werden konnte, wird eine Ausnahme geworfen
und bekanntgeben, dass die automatische Erkennung fehlgeschlagen ist.
</para>
</listitem>
</orderedlist>
</para>
<example id="zend.locale.selection.automatic.example-1">
<title>Verwenden automatischer Gebietsschemata</title>
<programlisting language="php"><![CDATA[
// ohne automatische Erkennung
//$locale = new Zend_Locale(Zend_Locale::BROWSER);
//$date = new Zend_Date($locale);
// mit automatischer Erkennung
$date = new Zend_Date('auto');
]]></programlisting>
</example>
</sect2>
<sect2 id="zend.locale.defaultlocale">
<title>Verwenden eines Standardgebietsschemas</title>
<para>
In einigen Umgebungen ist es nicht möglich automatisch ein Gebietsschema zu erkennen.
Man kann dieses Verhalten zum Beispiel sehen, wenn eine Anfrage von der Kommandozeile
kommt, oder der anfragende Browser kein Sprachtag gesetzt hat und zusätzlich der Server
das Standardgebietsschema 'C' gesetzt hat oder ein anderes propäritäres Gebietsschema.
</para>
<para>
In solchen Fällen wirft <classname>Zend_Locale</classname> normalerweise eine Ausnahme
mit einer Nachricht, dass die automatische Erkennung des Gebietsschemas nicht erfolgreich
war. Es gibt zwei Optionen um diese Situation handzuhaben. Entweder durch das Setzen
eines neuen Gebietsschemas per Hand, oder der Definition eines Standardgebietsschemas.
</para>
<example id="zend.locale.defaultlocale.example-1">
<title>Handhabung von Ausnahmen für Gebietsschemas</title>
<programlisting language="php"><![CDATA[
// In der Bootstrap Datei
try {
$locale = new Zend_Locale('auto');
} catch (Zend_Locale_Exception $e) {
$locale = new Zend_Locale('de');
}
// Im Modell/Controller
$date = new Zend_Date($locale);
]]></programlisting>
</example>
<para>
Aber das hat einen großen negativen Effekt. Man muß das Gebietsschema-Objekt in jeder
Klasse setzen, die <classname>Zend_Locale</classname> verwendet. Das kann sehr unhandlch
sein, wenn mehrere Klassen verwendet werden.
</para>
<para>
Seit Zend Framework Release 1.5 gibt es einen viel besseren Weg um das handzuhaben. Man
kann ein Standardgebietsschema mit der statischen <methodname>setDefault()</methodname>
Methode setzen. Natürlich wird jedes unbekannte oder nicht voll qualifizierte
Gebietsschema eine Ausnahme werfen. <methodname>setDefault()</methodname> sollte der
erste Aufruf sein, bevor irgendeine Klasse initiiert wird, die
<classname>Zend_Locale</classname> verwendet. Siehe das folgende Beispiel für Details:
</para>
<example id="zend.locale.defaultlocale.example-2">
<title>Setzen eines Standardgebietsschemas</title>
<programlisting language="php"><![CDATA[
// In der Bootstrap Datei
Zend_Locale::setDefault('de');
// Im Modell/Controller
$date = new Zend_Date();
]]></programlisting>
</example>
<para>
Für den Fall, dass kein Gebietsschema erkannt wird, wird automatisch das Gebietsschema
<emphasis>de</emphasis> verwendet. Andernfalls wird das erkannte Gebietsschema
verwendet.
</para>
</sect2>
<sect2 id="zend.locale.interoperate">
<title>ZF lokalisierbare Klassen</title>
<para>
Im Zend Framework sind lokalisierbare Klassen von <classname>Zend_Locale</classname>
abhängig, um ein Gebietsschema automatisch auszuwählen, wie im oberen Abschnitt
geschrieben. Das Erstellen eines Datums durch Verwendung von
<classname>Zend_Date</classname> ohne die Angabe eines Gebietsschemas führt als
Ergebnis zu einem Objekt mit einem Gebietsschema, basierend auf den Informationen,
welche durch den Webbrowser des Benutzers zur Verfügung gestellt werden.
</para>
<example id="zend.locale.interoperate.example-1">
<title>Daten verwenden das aktuelle Gebietsschema des Web Benutzers</title>
<programlisting language="php"><![CDATA[
$date = new Zend_Date('2006',Zend_Date::YEAR);
]]></programlisting>
</example>
<para>
Um dieses Standardverhalten zu übergehen, und eine lokalisierbare Zend Framework
Komponente dazu zu bringen ein spezielles Gebietsschema zu benutzen, welches unabhängig
vom Gebietsschema des Besucher der Webseite ist, muß als dritter Parameter im
Konstruktor das Gebietsschema angegeben werden.
</para>
<example id="zend.locale.interoperate.example-2">
<title>Übergehen der Auswahl des standardmäßigen Gebietsschemas</title>
<programlisting language="php"><![CDATA[
$usLocale = new Zend_Locale('en_US');
$date = new Zend_Date('2006', Zend_Date::YEAR, $usLocale);
$temp = new Zend_Measure_Temperature('100,10',
Zend_Measure::TEMPERATURE,
$usLocale);
]]></programlisting>
</example>
<para>
Wenn viele Objekte benutzt werden, die alle das gleiche Gebietsschema verwenden, sollte
das Gebietsschema explizit definiert werden, um die zusätzliche Arbeit jedes Objekts
durch die Bestimmung des standardmäßigen Gebietsschemas zu verringern.
</para>
<example id="zend.locale.interoperate.example-3">
<title>
Optimierung der Geschwindigkeit durch Benutzung eines Standard-Gebietsschemas
</title>
<programlisting language="php"><![CDATA[
$locale = new Zend_Locale();
$date = new Zend_Date('2006', Zend_Date::YEAR, $locale);
$temp = new Zend_Measure_Temperature('100,10',
Zend_Measure::TEMPERATURE,
$locale);
]]></programlisting>
</example>
</sect2>
<sect2 id="zend.locale.frameworkwidelocale">
<title>Anwendungsweites Gebietsschema</title>
<para>
Zend Framework erlaubt die Verwendung eines anwendungsweiten Gebietsschemas. Man kann
einfach eine Instanz von <classname>Zend_Locale</classname> in der Registry mit dem
Schüssel 'Zend_Locale' setzen. Dann wird diese Instanz in allen Klassen des Zend
Framework verwendet, die Gebietsschemata verwenden. Auf diesem Weg wird eine
Instanz in der Registry gesetzt und man kann dann das weitere Setzen vergessen. Sie wird
automatisch in allen anderen Klassen verwendet. Siehe das folgende Beispiel für die
richtige Verwendung:
</para>
<example id="zend.locale.frameworkwidelocale.example">
<title>Verwendung eines anwendungsweiten Gebietsschemas</title>
<programlisting language="php"><![CDATA[
// In der Bootstrap Datei
$locale = new Zend_Locale('de_AT');
Zend_Registry::set('Zend_Locale', $locale);
// Im Modell oder dem Controller
$date = new Zend_Date();
// print $date->getLocale();
echo $date->getDate();
]]></programlisting>
</example>
</sect2>
<sect2 id="zend.locale.formatoptions">
<title>Zend_Locale_Format::setOptions(array $options)</title>
<para>
Die Option 'precision' wird benutzt, um einen Wert zu verkürzen oder mit extra Ziffern zu
strecken. Ein Wert von '-1' verhindert die Veränderung der Anzahl an Ziffern im
Nachkommateil des Wertes. Die Option 'locale' hilft, wenn Nummern und Daten analysiert
werden und hierbei Trennzeichen oder Monatsnamen verwendet werden. Die Datumsformat
Option 'format_type' wählt zwischen <acronym>CLDR</acronym>/ISO Datumsdefinitionen und
<acronym>PHP</acronym>s date() Definitionen. Die Option 'fix_date' erlaubt oder
verhindert eine Automatik welche versucht falsche Daten zu korrigieren. Die Option
'number_format' definiert ein Standardformat für Nummern bei Verwendung der Funktion
<methodname>toNumber()</methodname>. (siehe <link
linkend= "zend.locale.number.localize">diesen Abschnitt</link>
).
</para>
<para>
Die Option 'date_format' kann verwendet werden um ein Standarddatumsformat zu
definieren. Aber Achtung bei der Verwendung von getDate(), checkDateFormat() und
getTime() nach der Verwendung von setOptions() mit einem 'date_format'. Um diese vier
Methoden mit einem Standard Datumsformat für ein Gebietsschema zu benutzen, muß
array('date_format' => null, 'locale' => $locale) in deren Optionen angegeben werden.
</para>
<example id="zend.locale.formatoptions.example-1">
<title>Daten die das richtige Gebietsschema des Web Benutzers verwenden</title>
<programlisting language="php"><![CDATA[
Zend_Locale_Format::setOptions(array('locale' => 'en_US',
'fix_date' => true,
'format_type' => 'php'));
]]></programlisting>
</example>
<para>
Um mit den Standarddefinitionen eines Gebietsschemas zu arbeiten kann die Konstante
<constant>Zend_Locale_Format::STANDARD</constant> verwendet werden. Das Setzen der
Konstante <constant>Zend_Locale_Format::STANDARD</constant> für
<property>date_format</property> benutzt die Standarddefinition des aktuellen
Gebietsschemas. Das Setzen für <property>number_format</property> benutzt das Standard
Nummernformat dieses Gebietsschemas. Und das Setzen für 'locale' verwendet das Standard
Gebietsschema des Servers oder Browsers.
</para>
<example id="zend.locale.formatoptions.example-2">
<title>Verwendung von STANDARD-Definitionen für setOptions()</title>
<programlisting language="php"><![CDATA[
Zend_Locale_Format::setOptions(array('locale' => 'en_US',
'date_format' => 'dd.MMMM.YYYY'));
// Das global gesetzte Datumsformat außer Kraft setzen
$date = Zend_Locale_Format::getDate('2007-04-20',
array('date_format' =>
Zend_Locale_Format::STANDARD);
// Das global gesetzte Standard-Gebietsschema außer Kraft setzen
Zend_Locale_Format::setOptions(array('locale' => Zend_Locale_Format::STANDARD,
'date_format' => 'dd.MMMM.YYYY'));
]]></programlisting>
</example>
</sect2>
<sect2 id="zend.locale.cache">
<title>Zend_Locale und dessen Subklassen beschleunigen</title>
<para>
<classname>Zend_Locale</classname> und dessen Subklassen können durch die Verwendung von
<classname>Zend_Cache</classname> beschleunigt werden. Man sollte die statische
Methode <methodname>Zend_Locale::setCache($cache)</methodname> verwenden, wenn man
<classname>Zend_Locale</classname> benutzt. <classname>Zend_Locale_Format</classname>
kann schneller gemacht werden, indem die Option <property>cache</property> innerhalb von
<classname>Zend_Locale_Format::setOptions(array('cache' => $adapter));</classname>
aufgerufen wird. Wenn beide Klassen verwendet werden, sollte nur für
<classname>Zend_Locale</classname> ein Cache gesetzt werden, da der zuletzt gesetzte
Cache den vorher gesetzten Cache überschreibt. Der Bequemlichkeit halber gibt es auch
die statischen Methoden <methodname>getCache()</methodname>,
<methodname>hasCache()</methodname>, <methodname>clearCache()</methodname> und
<methodname>removeCache()</methodname>.
</para>
<para>
Wenn kein Cache gesetzt wird, dann setzt <classname>Zend_Locale</classname> automatisch
von selbst einen Cache. Manchmal ist es gewünscht zu verhindern, dass ein Cache gesetzt
wird, selbst wenn das die Performance verringert. In diesem Fall sollte die statische
Methode <methodname>disableCache(true)</methodname> verwendet werden. Sie schaltet
nicht nur den aktuell gesetzten Cache aus, ohne ihn zu löschen, sondern verhindert auch,
dass ein Cache automatisch erstellt wird, wenn kein Cache gesetzt ist.
</para>
</sect2>
</sect1>
|