Cheia de acces n sare lanagigarea in pagina. Sari la inceputul continutului.

Acest document e o traducere. In caz ca apare vreo eroare sau discrepanta, ultima versiune in Engleza este cea autoritativa. Copyright-ul original apartine W3C, dupa cum e aratat mai jos.

Traducator: Echipa Traduceri-w3

s_gotoW3cHome Internationalizare
 

Formate pentru data

Cititorii vizati: XHTML/HTML coders (using editors or scripting), script developers (PHP, JSP, etc.), Web project managers, and anyone who wants to know how to handle international date formats.

Intrebare

Cum imi pregatesc paginile mele web pentru a putea afisa diferite formate internationale pentru data?

Introducere

Vizitatorii unui site care apartin unor locatii diferite pot avea probleme la intelegerea datii. Formatul LL/ZZ/AA este unic pentru Statele Unite ale Americii. Majoritatea din Europa folosesc ZZ/LL/AA. Japonia foloseste AA/LL/ZZ. Separatorii pot fi puncturi, bare sau virgule. Unii folosesc zero-urile pentru ajustarea datii, altii le omit. Daca un vorbitor nativ de japoneza citeste o pagina web in engleza US a unui site din Germania, cum va interpreta data 03/04/02 ?

Raspuns

Primul impuls este sa presupunem ca problema va fi rezolvata in masura localizarii paginilor web - de exemplu, sa fie rezolvata de traducere. Nu asta este solutia. Chiar vreti sa pastrati o copie pentru SUA si o copie pentru Anglia cand singurul lucru care difera e formatul datei? In orice caz, tot trebuie sa aveti in vedere utilizatorii multilinguali ca in exemplul precedent.

Exista trei optiuni, fiecare cu avantaje si dezavantaje:

  1. Folosirea unui format neutru local
  2. Scoaterea in evidenta a lunii si a anului
  3. Folosirea header-ului HTTP Accept-Language

Optiunea 1: Folosirea unui format neutru local

ISO 8601 specifica urmatorul format : AAAA-LL-ZZ. 2003-04-02 este mai clar decat 03/04/02 ( Unii prefera sa modifice ISO 8601 folosint o abreviere pentru luna pentru a o face mai clara, de exemplu 2003-Apr-02, dar aceasta deja nu mai este un format local neutru).

Avantaje:

Dezavantaje:

Optiunea 2: Scoaterea in evidenta a lunii si a anului

Pentru aceasta se foloseste numelei lunii (abreviat sau nu ) si se folosesc 4 caractere pentru toti anii calendarului Gregorian. De exemplu, 2 Aprilie 2003.

Avantaje:

Dezavantaje:

Optiunea 3: Folosirea header-ului HTTP Accept-Language

Header-ul HTTP Accept-Language specifica doar preferintele de limbaj ale utilizatorului, dar este folosit deseori pentru a determina preferintele locale de asemenea.

Aceasta metoda functioneaza bine pentru documentele web generate dinamic cand se insereaza o data dintr-o arhiva, atata timp cat asteptarile utilizatorului asupra formatului darte sunt clare. Adecvarea este o functie a contextului lingvistic , nu doar o simpla setare a browser-ului folosit de utilizator. De exemplu:

Cum va fi realizata aceasta, va depinde de mediul de dezvoltare.Urmeaza niste indicatori pentru medii cunoscute:

Java/JSP

Acceseaza metoda getLocale a ServletRequest sau obiectul HttpServletRequest. Foloseste obiectul Locale returnat pentru a accesa DateFormat. Acest format SHORT foloseste numai numere. Daca vrei formate clare foloseste FULL. In unele regiuni chiar si formatul LONG este numeric in totalitate.

Vezi de asemenea ICU4J deoarece contine date mai recente (si mai functionale) decat rutinele JDK.

ASP

Foloseste Request.ServerVariables('HTTP_ACCEPT_LANGUAGE') pentru a accesa preferintele utilizatorului. Alegeti prima optiuni din lista de optiuni acceptate. Va trebui sa va creati propria cartografiere din codul local alfabetic intr-un Indentificator Numeri Local. Seteaza Session.LCID catre valorile rezultate. Seteaza FormatDateTime la formatul datei.

Foloseste vbLongDate pentru a evita ambiguitatea.

Perl

Foloseste $ENV{'HTTP_ACCEPT_LANGUAGE'} pentru a seta limba preferata. Foloseste POSIX:strftime pentru a formata valorile datei. Vei fi nevoit sa cartografiezi singur limbile acceptate cu formatul datei.

Sumar

Nu exista solutii ideale pentru aceasta problema. Cantariti optiunile si alegeti in functie de preferintele sau situatia ta.

Daca exista sanse de ambiguitate din partea utilizatorului, cel mai bine este sa folosesti nume explicit pentru luna si anul sa fie exprimat prin 4 caractere pentru datele Gregorienr, sau macar sa indicati in josul paginii cum sa fie citita data.

Data poate fi reformata folosind tehnici dinamice pentru a de potrivi contextului lingvistic al paginii.

Apropo

Unii au pledat pentru crearea Tag-ului <date> care ar putea afisa data in functie de localizarea utilizatorului. Acest subiect are aceleasi probleme practice ca si cele descrise pentru generarea dinamica a datei prin Exemplul Japonez. Formatul potrivit este, in general, o functie a contextului lingvistic al paginii, nu al platformei utilizatorului.

Spune-ne părerea ta (în Engleză).

Abonează-te la RSS feed.

Resurse noi

Noutăţi prima pagină

Twitter (Noutăţi prima pagină)

‎@webi18n

Alte materiale

Autor: Lloyd Honomichl, Lionbridge. Modificat de: Richard Ishida, W3C. Traducator: Echipa Traduceri-w3.

XHTML 1.0 Valid!
CSS Valid!
Incodat cu UTF-8!

Tradus din engleza: 2007-07-04. Ultima modificare a traducerii: 2010-01-29 12:34 GMT

Pentru a vedea toate schimbarile documentului, cauta qa-date-format pe blogul i18n.