Asa este. Exact avertismente de genul acesta ma gandeam ca ar fi bine sa fie oferite de acel plugin. Daca nici cu asa ceva unii tot nu vor sa adauge acel contentDescription inseamna ca e putin probabil ca ei sa faca ulterior eforturi pentru a imbunatati accesibilitatea, deci cu acei programatori tot nu avem sanse de izbanda.
Dar cine stie, acea descriere poate ca nici nu este inteleasa de toti programatorii. La cati programatori pentru Android sunt, sunt sigur ca exista destui care au auzit de termenul "screen reader" dar habar nu au ce e ala si nici nu ii intereseaza atat timp cat pot sa seteze "ignore" rapid si sa treaca mai departe.
Programare pentru Android, accesibilizare aplicatii
-
Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Ramasesem dator cu modul in care se pot utiliza placeholders pentru stringuri astfel incat sa fie usor de localizat:
Se poate formata un string utilizand String.format(String, Object...), primul parametru fiind resursa string din fisierul XML, urmatorii fiind valorile de care este nevoie pentru a inlocui acele placeholders.
De exemplu, pentru urmatoarea resursa:
In res / values / strings.xml, pentru limba de baza, de obicei engleza:
<string name="our_message">Hello, %1$s! You need to pay %2$d dollars.</string>
In res / values-ro / strings.xml, pentru limba romana:
<string name="our_message">Salut %1$s! trebuie să plăteşti %2$d dolari.</string>
In acest exemplu, format string are nevoie de trei parametri: primul este resursa din XML, apoi doua valori, un string si un numar zecimal.
Se poate formata stringul asadar utilizand valori ale variabilelor din aplicatie:
Mesajul va fi:
Daca telefonul e pe romana -
"Salut Manu! Trebuie să plăteşti 10 dolari."
Daca telefonul e pe engleza sau alta limba decat romana -
"Hello Manu! You need to pay 10 dollars."
Se mai pot face multe lucruri cu aceste string-uri, precum: stocarea de array-uri in resurse de tip string_array, se pot specifica formatari HTML etc.
Intr-adevar, e mai mult de lucru si e un limbaj foarte verbose, trebuie sa scrii ceva cod ca sa ajungi ca totul sa fie bine. E adevarat ca in final e foarte usor, ii dai cuiva fisierul strings.xml din value, il traduce pentru limba maghiara si apoi nu mai trebuie facut decat un folder numit values-hu in care se pune strings.xml tradus; cand telefonul e mutat pe maghiara, aplicatia se conformeaza si apare in aceasta limba.
Daca e sa gasesc ceva neconvenabil, este ca tot timpul va trebui intervenit programmatic asupra unui string, nu mai poate fi bagat sub forma lui implicita pe un View pentru ca ar aparea cu tot cu %1$s, ca si cum asa ar fi el de afisat.
Trebuie se pare ca la aparitia unei ferestre in care ar fi sus sa zicem un TextView cu salut personalizat, sa nu existe atributul android:text in fisierul XML Layout, ci sa fie pus mesajul cu .setText(). In unele cazuri ar fi si Solutia sa existe o resursa string implicita cu valori implicite si una cu placeholders care sa apara apoi cu valori diferite la rulare.
Se poate formata un string utilizand String.format(String, Object...), primul parametru fiind resursa string din fisierul XML, urmatorii fiind valorile de care este nevoie pentru a inlocui acele placeholders.
De exemplu, pentru urmatoarea resursa:
In res / values / strings.xml, pentru limba de baza, de obicei engleza:
<string name="our_message">Hello, %1$s! You need to pay %2$d dollars.</string>
In res / values-ro / strings.xml, pentru limba romana:
<string name="our_message">Salut %1$s! trebuie să plăteşti %2$d dolari.</string>
In acest exemplu, format string are nevoie de trei parametri: primul este resursa din XML, apoi doua valori, un string si un numar zecimal.
Se poate formata stringul asadar utilizand valori ale variabilelor din aplicatie:
Cod: Selectaţi tot
String my_name = "Manu";
int price = 10;
Resources res = getResources();
String text = String.format(res.getString(R.string.our_message), my_name, price);
Daca telefonul e pe romana -
"Salut Manu! Trebuie să plăteşti 10 dolari."
Daca telefonul e pe engleza sau alta limba decat romana -
"Hello Manu! You need to pay 10 dollars."
Se mai pot face multe lucruri cu aceste string-uri, precum: stocarea de array-uri in resurse de tip string_array, se pot specifica formatari HTML etc.
Intr-adevar, e mai mult de lucru si e un limbaj foarte verbose, trebuie sa scrii ceva cod ca sa ajungi ca totul sa fie bine. E adevarat ca in final e foarte usor, ii dai cuiva fisierul strings.xml din value, il traduce pentru limba maghiara si apoi nu mai trebuie facut decat un folder numit values-hu in care se pune strings.xml tradus; cand telefonul e mutat pe maghiara, aplicatia se conformeaza si apare in aceasta limba.
Daca e sa gasesc ceva neconvenabil, este ca tot timpul va trebui intervenit programmatic asupra unui string, nu mai poate fi bagat sub forma lui implicita pe un View pentru ca ar aparea cu tot cu %1$s, ca si cum asa ar fi el de afisat.
Trebuie se pare ca la aparitia unei ferestre in care ar fi sus sa zicem un TextView cu salut personalizat, sa nu existe atributul android:text in fisierul XML Layout, ci sa fie pus mesajul cu .setText(). In unele cazuri ar fi si Solutia sa existe o resursa string implicita cu valori implicite si una cu placeholders care sa apara apoi cu valori diferite la rulare.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
Intr-adevar, se pare ca singura mare problema pe care o are Java este ca este foarte verbose si trebuie sa scri mult mai mult, dar foloseste cam aceeasi metoda de internationalizare ca gettext/maketext.
Cu aceste limbaje este usor de internationalizat o aplicatie. Exista chiar un program numit poedit care este foarte accesibil si pentru orbi, si care cred ca are variante pentru mai multe sisteme de operare. In el se afiseaza o lista cu stringurile traduse si netraduse si dupa ce se selecteaza unul dintre ele se poate scrie traducerea intr-un camp de editare. La salvare se salveaza un fisier cu extensia .po care are un format mult mai clar si mai usor de editat chiar manual cu un editor de text. Se salveaza de asemenea un fisier .mo in forma compilata. Sub Linux si Mac am inteles ca se pot folosi si alte programe cum ar fi emacs pentru a crea fisiere .po/.mo. In fisierul ro.po apar perechi de linii in care primul element este ID-ul iar al doilea stringul tradus. Iar elementele variabile pot aparea sub forma numerotata cu %1, %2 sau [_1], [_2].
Exemplul tau ar putea fi:
msgid "our_message"
msgstr "Salut [_1], trebuie să plăteşti [_2] dolari."
Doar ca ar putea afisa o fraza mai putin corecta, de forma:
Salut Manu, trebuie să plăteşti 1 dolari.
Si atunci poti utiliza functia quant pentru a face sa apara "dolari" cand variabila este mai mare decat 1 si "dolar" cand este egala cu 1:
msgid "our_message"
msgstr "Salut [_1], trebuie să plăteşti [quant,_2,dolar,dolari]."
Se vor afisa mesaje de genul:
Salut Manu, trebuie să plăteşti 1 dolar.
Salut Manu, trebuie să plăteşti 3 dolari.
In plus se poate specifica si o varianta negativa pentru cazul in care variabila este zero. Avantajul acestei metode este ca aceasta facilitate se poate aplica doar acolo unde este nevoie, in fisierele cu traduceri pentru limbile care necesita asa ceva, nu pentru toate limbile, fiindca poate ca in unele limbi nu exista diferente intre singularul si pluralul substantivelor.
Iar localizarea se face ca in Java, cu o metoda care accepta ca prim parametru cheia traducerii si apoi lista variabilelor care trebuie inlocuite:
loc('our_message', 'Manu', 3);
Unde evident, in loc de "Manu" si "3" sunt de obicei variabile care contin aceste valori.
Cum si Java spui ca foloseste etichete de genul %1, %2, ma gandesc ca si in Java se pot folosi functii de cuantificare probabil in forma %{quant,1,dolar,dolari} sau ceva asemanator.
In programul Maestro Translate am facut o functie scurta de vreo 3 randuri care sa faca localizarea nu pe baza unei liste cu valori, fiindca ar fi mai dificil daca ar trebui ca la un moment dat sa apara o lista cu multe valori in aceeasi expresie, ci pe baza unei matrici asociative, adica hash. In acel caz in fisierul cu traduceri in locul variabilelor nu apar numere, ci numele variabilelor:
msgid "our_message"
msgstr "Salut {nume} trebuie să plăteşti {suma} dolari."
In acest caz localizarea se face cu:
loc('our_message', nume => 'Manu', suma => 3);
Exista de asemenea programe ajutatoare care analizeaza diverse tipuri de fisiere in care se apeleaza functia de traducere pentru stringuri, de exemplu fisiere program, diverse tipuri de fisiere de configurare sau template-uri, si care extrag din ele toate ID-urile existente si creaza fisierul .po initial sau il actualizeaza cu noi termeni adaugati pana in acel moment, urmand ca ei sa fie apoi tradusi. Nu este deci nevoie sa tot completezi manual fisierul .po ci singura munca manuala este cea de traducere, dar si aceea cu o interfata prietenoasa. Pe langa acele perechi cu ID-ul si stringul tradus acele programe mai adauga inainte si linii de comentariu care spun unde a fost intalnit respectivul string, adica in care template sau program la linia numarul cutare si cutare etc fiindca asta le-ar putea fi util traducatorilor ca sa vada si contextul.
Nu cred ca am inteles bine acea problema legata de faptul ca se afiseaza stringurile cu %1$s. Cand se afiseaza asa? Cand in fisierul pentru o anumita limba nu contine cheia asociata cu acel string? Sau cum sa il bagi direct intr-un view? Banuiesc ca acolo trebuie intotdeauna sa folosesti varianta tradusa, nu?
Cu aceste limbaje este usor de internationalizat o aplicatie. Exista chiar un program numit poedit care este foarte accesibil si pentru orbi, si care cred ca are variante pentru mai multe sisteme de operare. In el se afiseaza o lista cu stringurile traduse si netraduse si dupa ce se selecteaza unul dintre ele se poate scrie traducerea intr-un camp de editare. La salvare se salveaza un fisier cu extensia .po care are un format mult mai clar si mai usor de editat chiar manual cu un editor de text. Se salveaza de asemenea un fisier .mo in forma compilata. Sub Linux si Mac am inteles ca se pot folosi si alte programe cum ar fi emacs pentru a crea fisiere .po/.mo. In fisierul ro.po apar perechi de linii in care primul element este ID-ul iar al doilea stringul tradus. Iar elementele variabile pot aparea sub forma numerotata cu %1, %2 sau [_1], [_2].
Exemplul tau ar putea fi:
msgid "our_message"
msgstr "Salut [_1], trebuie să plăteşti [_2] dolari."
Doar ca ar putea afisa o fraza mai putin corecta, de forma:
Salut Manu, trebuie să plăteşti 1 dolari.
Si atunci poti utiliza functia quant pentru a face sa apara "dolari" cand variabila este mai mare decat 1 si "dolar" cand este egala cu 1:
msgid "our_message"
msgstr "Salut [_1], trebuie să plăteşti [quant,_2,dolar,dolari]."
Se vor afisa mesaje de genul:
Salut Manu, trebuie să plăteşti 1 dolar.
Salut Manu, trebuie să plăteşti 3 dolari.
In plus se poate specifica si o varianta negativa pentru cazul in care variabila este zero. Avantajul acestei metode este ca aceasta facilitate se poate aplica doar acolo unde este nevoie, in fisierele cu traduceri pentru limbile care necesita asa ceva, nu pentru toate limbile, fiindca poate ca in unele limbi nu exista diferente intre singularul si pluralul substantivelor.
Iar localizarea se face ca in Java, cu o metoda care accepta ca prim parametru cheia traducerii si apoi lista variabilelor care trebuie inlocuite:
loc('our_message', 'Manu', 3);
Unde evident, in loc de "Manu" si "3" sunt de obicei variabile care contin aceste valori.
Cum si Java spui ca foloseste etichete de genul %1, %2, ma gandesc ca si in Java se pot folosi functii de cuantificare probabil in forma %{quant,1,dolar,dolari} sau ceva asemanator.
In programul Maestro Translate am facut o functie scurta de vreo 3 randuri care sa faca localizarea nu pe baza unei liste cu valori, fiindca ar fi mai dificil daca ar trebui ca la un moment dat sa apara o lista cu multe valori in aceeasi expresie, ci pe baza unei matrici asociative, adica hash. In acel caz in fisierul cu traduceri in locul variabilelor nu apar numere, ci numele variabilelor:
msgid "our_message"
msgstr "Salut {nume} trebuie să plăteşti {suma} dolari."
In acest caz localizarea se face cu:
loc('our_message', nume => 'Manu', suma => 3);
Exista de asemenea programe ajutatoare care analizeaza diverse tipuri de fisiere in care se apeleaza functia de traducere pentru stringuri, de exemplu fisiere program, diverse tipuri de fisiere de configurare sau template-uri, si care extrag din ele toate ID-urile existente si creaza fisierul .po initial sau il actualizeaza cu noi termeni adaugati pana in acel moment, urmand ca ei sa fie apoi tradusi. Nu este deci nevoie sa tot completezi manual fisierul .po ci singura munca manuala este cea de traducere, dar si aceea cu o interfata prietenoasa. Pe langa acele perechi cu ID-ul si stringul tradus acele programe mai adauga inainte si linii de comentariu care spun unde a fost intalnit respectivul string, adica in care template sau program la linia numarul cutare si cutare etc fiindca asta le-ar putea fi util traducatorilor ca sa vada si contextul.
Nu cred ca am inteles bine acea problema legata de faptul ca se afiseaza stringurile cu %1$s. Cand se afiseaza asa? Cand in fisierul pentru o anumita limba nu contine cheia asociata cu acel string? Sau cum sa il bagi direct intr-un view? Banuiesc ca acolo trebuie intotdeauna sa folosesti varianta tradusa, nu?
-
Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Cand spuneam de aparitia string-ului neformatat, ma refeream la faptul ca pentru Android, de obicei se poate specifica ca atribut in XML-ul care creeaza interfata unei ferestre textul unui element view in felul urmator:
In acest caz ar aparea afisat stringul asa cum este el in strings.xml, adica:
"Salut %1$s! Trebuie să plăteşti %2$d dolari"
Asadar trebuie de la inceput sa nu mai pui text la buton in XML, ci sa il pui cu .setText dupa ce utilizezi stringFormat().
Asta va duce probabil si la afisarea avertismentului ca acel <button> nu are setat niciun text sau un contentDescription, nu cred ca IDE-ul isi da seama ca a fost pus in alta parte prin codul propriu-zis un text. De aceea spuneam ca poate ar trebui si un text implicit care sa fie modificat ulterior cu stringFormat() si setText().
<string name="our_text_init">Bine ai venit, deocamdată nu trebuie să plăteşti nimic</string>
In fine, nu conteaza asta, pana la urma aceeasi problema ar fi in toate limbajele, doar ca aici exista posibilitatea asta de a declara textul inca de la stabilirea interfetei intr-un mod static, extern de codul Java propriu-zis.
Este prevazuta si problema cantitatii, pentru asta exista resursa numita plurals, utilizata chiar in fisierul strings.xml la fel ca resursa string. Se poate crea si alt fisier XML, preluarea acestor resurse nu depind de numele fisierelor, ci de numele lor ca tag.
De exemplu, un fisier pentru engleza care contine plurals:
Intamplarea face ca si in limba romana sa fie cam la fel, adica doar la 1 este utilizat singularul substantivului, iar la others, adica orice altceva inclusiv 0 sa fie substantivul la plural.
Totusi, pentru romana e cam ciudat sa pui cifra 2 si apoi sa apara cantece, ar suna "doi cantece", iar pentru 1 ar suna "unu cantec", cel putin citit de un sintetizor.
Astfel, pentru limba romana aceeasi secventa plurals ar fi:
Ar exista ca posibilitati:
quantity=["zero" | "one" | "two" | "few" | "many" | "other"]
Ne putem referi la una dintre posibilitati utilizand functia
getQuantityString();
Daca getQuantityString() pentru limba engleza la parametru primeste valoarea 1 va prelua prima exprimare, daca primeste alta valoare, va prelua a doua exprimare.
Pentru romana ar fi un comportament diferit pentru 1, 2 sau altceva.
Cand se utilizeaza metoda getQuantityString(), trebuie pusa de doua ori variabila count daca se are in vedere si inlocuirea unui placeholder cu un numar de itemi.
De exemplu, pentru stringul %d songs found, primul parametru count selecteaza string-ul de plural adecvat, iar al doilea parametru count este inserat in locul placeholder-ului %d.
Cod: Selectaţi tot
<button
android:text="@string/our_message" />
"Salut %1$s! Trebuie să plăteşti %2$d dolari"
Asadar trebuie de la inceput sa nu mai pui text la buton in XML, ci sa il pui cu .setText dupa ce utilizezi stringFormat().
Asta va duce probabil si la afisarea avertismentului ca acel <button> nu are setat niciun text sau un contentDescription, nu cred ca IDE-ul isi da seama ca a fost pus in alta parte prin codul propriu-zis un text. De aceea spuneam ca poate ar trebui si un text implicit care sa fie modificat ulterior cu stringFormat() si setText().
<string name="our_text_init">Bine ai venit, deocamdată nu trebuie să plăteşti nimic</string>
In fine, nu conteaza asta, pana la urma aceeasi problema ar fi in toate limbajele, doar ca aici exista posibilitatea asta de a declara textul inca de la stabilirea interfetei intr-un mod static, extern de codul Java propriu-zis.
Este prevazuta si problema cantitatii, pentru asta exista resursa numita plurals, utilizata chiar in fisierul strings.xml la fel ca resursa string. Se poate crea si alt fisier XML, preluarea acestor resurse nu depind de numele fisierelor, ci de numele lor ca tag.
De exemplu, un fisier pentru engleza care contine plurals:
Cod: Selectaţi tot
<?xml version="1.0" encoding="utf-8"?>
<resources>
<plurals name="numberOfSongsAvailable">
<item quantity="one">One song found.</item>
<item quantity="other">%d songs found.</item>
</plurals>
</resources>
Totusi, pentru romana e cam ciudat sa pui cifra 2 si apoi sa apara cantece, ar suna "doi cantece", iar pentru 1 ar suna "unu cantec", cel putin citit de un sintetizor.
Astfel, pentru limba romana aceeasi secventa plurals ar fi:
Cod: Selectaţi tot
<?xml version="1.0" encoding="utf-8"?>
<resources>
<plurals name="numberOfSongsAvailable">
<item quantity="one">Un cântec găsit.</item>
<item quantity="two">Două cântece găsite.</item>
<item quantity="other">%d cântece găsite.</item>
</plurals>
</resources>
Ar exista ca posibilitati:
quantity=["zero" | "one" | "two" | "few" | "many" | "other"]
Ne putem referi la una dintre posibilitati utilizand functia
getQuantityString();
Cod: Selectaţi tot
int count = getNumberOfSongsAvailable();
Resources res = getResources();
String songsFound = res.getQuantityString(R.plurals.numberOfSongsAvailable, count, count);
Pentru romana ar fi un comportament diferit pentru 1, 2 sau altceva.
Cand se utilizeaza metoda getQuantityString(), trebuie pusa de doua ori variabila count daca se are in vedere si inlocuirea unui placeholder cu un numar de itemi.
De exemplu, pentru stringul %d songs found, primul parametru count selecteaza string-ul de plural adecvat, iar al doilea parametru count este inserat in locul placeholder-ului %d.
Ultima oară modificat 26 Iun 2015, 20:36 de către Manu, modificat de 2 ori în total.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
O, dar e verbose nu gluma! 
Cred ca codul XML de care e nevoie nu e mai mic decat codul de programare de care ar fi fost nevoie daca s-ar fi folosit if/elsif/else, atat doar ca XML e un marcaj standard care poate fi eventual completat automat de alte programe.
Acum am inteles ce spuneai de preluarea literala a textului din fisierul XML, dar nu cred ca asta este o limitare. Adica ma gandesc ca chiar daca si pentru definirea unor etichete textuale simple si pentru definirea unor etichete folosite pentru internationalizare se folosesc tot fisiere XML intr-un mod similar, scopul lor nu este de a fi folosite in acelasi mod, fiindca cele folosite pentru internationalizare trebuie in mod evident prelucrate in momentul rularii in functie de limba aleasa, deci de catre program, iar daca sunt preluate automat, e normal ca apar in forma bruta.
Ar fi intr-adevar bine daca ar sti sa preia textul dinamic cand este setat cu setText() dar sa preia alte atribute cum este contentDescription direct din fisierul XML, ca sa nu trebuiasca sa setezi toate atributele din program.
Cred ca codul XML de care e nevoie nu e mai mic decat codul de programare de care ar fi fost nevoie daca s-ar fi folosit if/elsif/else, atat doar ca XML e un marcaj standard care poate fi eventual completat automat de alte programe.
Acum am inteles ce spuneai de preluarea literala a textului din fisierul XML, dar nu cred ca asta este o limitare. Adica ma gandesc ca chiar daca si pentru definirea unor etichete textuale simple si pentru definirea unor etichete folosite pentru internationalizare se folosesc tot fisiere XML intr-un mod similar, scopul lor nu este de a fi folosite in acelasi mod, fiindca cele folosite pentru internationalizare trebuie in mod evident prelucrate in momentul rularii in functie de limba aleasa, deci de catre program, iar daca sunt preluate automat, e normal ca apar in forma bruta.
Ar fi intr-adevar bine daca ar sti sa preia textul dinamic cand este setat cu setText() dar sa preia alte atribute cum este contentDescription direct din fisierul XML, ca sa nu trebuiasca sa setezi toate atributele din program.
-
Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Intr-adevar, cu if ... else if ... else ar fi poate chia rmai putin cod, dar ei spun ca asta e pentru localizare / internationalizare, un traducator iar doar XML-ul si ii este usor sa potriveasca lucrurile incat sa mearga bine pentru limba lui.
Cu if ar fi si un numar fix de ramuri, ar trebui prevazute toate posibilitatile, iar cel care traduce, in cazul unor limbi ar trebui sa scrie de mai multe ori aceeasi fraza daca de exemplu pentru 0 si 2 itemi e aceeasi exprimare.
Dupa cum spuneam, cine vrea sa traduca un program, primeste doar fisierul strings.xml si acolo face ce vrea, traduce cum vrea, adauga cati itemi vrea pentru un plurals. Programatorul nu trebuie decat sa creeze inca un folder numit "values-lang", unde "lang" este codul oricarei limbi, folder in care sa puna fisierul strings.xml tradus.
In aceasta privinta, codul pentru Android este de un nivel foarte inalt, nu mai iti bati capul cu alegerea limbii si cu crearea de cod pentru aceasta. Sunt unii care totusi au ambitia sa puna optiune de alegere a limbii, se gandesc ca desi ai telefonul pe engleza, vrei un anume program in alta limba.
In acel values mai este si un fisier dimens.xml unde se pot seta marimile diferitelor elemente grafice, padding-ul, marimea textului etc. Acel dimens.xml poate fi modificat pentru folderul value-de sa zicem, spun ei ca limba germana are stringuri mai lungi si poate vrei sa faci textul putin mai mic sau controlul putin mai mare etc.
Cu if ar fi si un numar fix de ramuri, ar trebui prevazute toate posibilitatile, iar cel care traduce, in cazul unor limbi ar trebui sa scrie de mai multe ori aceeasi fraza daca de exemplu pentru 0 si 2 itemi e aceeasi exprimare.
Dupa cum spuneam, cine vrea sa traduca un program, primeste doar fisierul strings.xml si acolo face ce vrea, traduce cum vrea, adauga cati itemi vrea pentru un plurals. Programatorul nu trebuie decat sa creeze inca un folder numit "values-lang", unde "lang" este codul oricarei limbi, folder in care sa puna fisierul strings.xml tradus.
In aceasta privinta, codul pentru Android este de un nivel foarte inalt, nu mai iti bati capul cu alegerea limbii si cu crearea de cod pentru aceasta. Sunt unii care totusi au ambitia sa puna optiune de alegere a limbii, se gandesc ca desi ai telefonul pe engleza, vrei un anume program in alta limba.
In acel values mai este si un fisier dimens.xml unde se pot seta marimile diferitelor elemente grafice, padding-ul, marimea textului etc. Acel dimens.xml poate fi modificat pentru folderul value-de sa zicem, spun ei ca limba germana are stringuri mai lungi si poate vrei sa faci textul putin mai mic sau controlul putin mai mare etc.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
Da, sigur, nu se pune problema sa faci internationalizarea cu if/else, fiindca este un cod de programare, nu de marcare, iar pentru traducatori ar fi mult mai complicat, nu s-ar putea crea interfete care sa citeasca si scrie in fisierele cu traduceri etc.
Ce nu imi place mie insa este limbajul XML care teoretic este usor de inteles si de computer si de oameni, dar practic este mult mai dificil de lucrat cu el decat cu alte limbaje de marcare tocmai fiindca implica mult cod. De aceea nici in request-urile AJAX pe web nu prea se mai foloseste XML, ci JSON, deci ar trebui sa ii spuna AJAJ.
XML este si el bun, pentru fisierele de dimensiuni foarte mari de exemplu, din alea care au cel putin cateva sute de mega, fiindca pot fi citite progresiv, fara sa trebuiasca a fi incarcate in intregime in memorie. Nu este insa cazul fisierelor de configurare sau al celor cu traduceri.
Este intr-adevar bine ca interfata este generata dinamic in momentul rularii in functie de parametrii din fisierul XML si nu are dimensiunile controalelor hard-coded in program.
Eu cred ca este utila acea facilitate de a oferi utilizatorilor posibilitatea de a isi alege limba interfetei. Pe telefon nu pot spune ca mie personal imi este utila, dar eu nici nu folosesc cine stie cat de mult telefonul, asa ca daca a venit cu interfata in romana si vocea in romana, sa fie sanatos, asa l-am lasat. Dar pe computer ma dispera unii de genul celor de la Mozilla care iti dau batai de cap in plus ca sa instalezi browserul Firefox in engleza si nu in romana si trebuie sa cauti pagina din care poti alege browsere si in alte limbi.
Eu am browserul setat sa prefere limba romana si abia apoi engleza, fiindca daca un site ofera si o versiune in romana, este mai usor de inteles decat cea in engleza, dar sunt mai usor de inteles explicatiile de pe site si toate povestile de acolo, nu interfata unui program care foloseste termeni in romana despre care nu stiu ce inseamna, care mai implica si folosirea unor combinatii de taste diferite etc.
Din acest motiv cred ca este bine sa poti alege. Dar cum ziceam, pe telefon... nu stiu daca are aceeasi importanta fiindca se folosesc termeni tehnici diferiti.
Pe computer poate ca unii s-au obisnuit cu termenii in engleza cu care au lucrat de 20 de ani si nu au motive sa faca eforturi in plus ca sa foloseasca alti termeni, dar pe telefoanele ocoshe sigur nu au lucrat atat de mult timp, si in plus ele au oferit interfete in mai multe limbi de mult timp.
Ce nu imi place mie insa este limbajul XML care teoretic este usor de inteles si de computer si de oameni, dar practic este mult mai dificil de lucrat cu el decat cu alte limbaje de marcare tocmai fiindca implica mult cod. De aceea nici in request-urile AJAX pe web nu prea se mai foloseste XML, ci JSON, deci ar trebui sa ii spuna AJAJ.
XML este si el bun, pentru fisierele de dimensiuni foarte mari de exemplu, din alea care au cel putin cateva sute de mega, fiindca pot fi citite progresiv, fara sa trebuiasca a fi incarcate in intregime in memorie. Nu este insa cazul fisierelor de configurare sau al celor cu traduceri.
Este intr-adevar bine ca interfata este generata dinamic in momentul rularii in functie de parametrii din fisierul XML si nu are dimensiunile controalelor hard-coded in program.
Eu cred ca este utila acea facilitate de a oferi utilizatorilor posibilitatea de a isi alege limba interfetei. Pe telefon nu pot spune ca mie personal imi este utila, dar eu nici nu folosesc cine stie cat de mult telefonul, asa ca daca a venit cu interfata in romana si vocea in romana, sa fie sanatos, asa l-am lasat. Dar pe computer ma dispera unii de genul celor de la Mozilla care iti dau batai de cap in plus ca sa instalezi browserul Firefox in engleza si nu in romana si trebuie sa cauti pagina din care poti alege browsere si in alte limbi.
Eu am browserul setat sa prefere limba romana si abia apoi engleza, fiindca daca un site ofera si o versiune in romana, este mai usor de inteles decat cea in engleza, dar sunt mai usor de inteles explicatiile de pe site si toate povestile de acolo, nu interfata unui program care foloseste termeni in romana despre care nu stiu ce inseamna, care mai implica si folosirea unor combinatii de taste diferite etc.
Din acest motiv cred ca este bine sa poti alege. Dar cum ziceam, pe telefon... nu stiu daca are aceeasi importanta fiindca se folosesc termeni tehnici diferiti.
Pe computer poate ca unii s-au obisnuit cu termenii in engleza cu care au lucrat de 20 de ani si nu au motive sa faca eforturi in plus ca sa foloseasca alti termeni, dar pe telefoanele ocoshe sigur nu au lucrat atat de mult timp, si in plus ele au oferit interfete in mai multe limbi de mult timp.
-
Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Da, eu prefer pe calculator toate programele in engleza, asa cum este si Windows-ul. Totusi, probabil deoarece la Regional settings am setata ca locatie Romania, la fel si la Formats e pe Romanian, de multe ori mi se instaleaza aplicatii in romana.
E ciudat ca pe telefon m-am obisnuit cu romana inca de pe vremea primelor Nokia, desi Windows si atunci il utilizam tot in engleza. Probabil asta e si din cauza ca pe cand am inceput sa utilizez un PC nu era o varianta in limba romana pentru Windows 98.
Nu imi place limba romana pe calculator pentru ca orice informatii pe internet sunt in engleza... e mai usor sa fii printre cei multi unde se gaseste cineva sa te ajute, decat sa te chinui printre cei putini.
E ciudat ca pe telefon m-am obisnuit cu romana inca de pe vremea primelor Nokia, desi Windows si atunci il utilizam tot in engleza. Probabil asta e si din cauza ca pe cand am inceput sa utilizez un PC nu era o varianta in limba romana pentru Windows 98.
Nu imi place limba romana pe calculator pentru ca orice informatii pe internet sunt in engleza... e mai usor sa fii printre cei multi unde se gaseste cineva sa te ajute, decat sa te chinui printre cei putini.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
Cam asa si eu. M-am obisnuit cu termenii in engleza folositi inca de pe vremea MS DOS, apoi in Windows-urile alea antice versiunea 3.x. Acum termenii in romana sunt tradusi uneori intr-un mod ciudat incat e clar ca nu ma pot obisnui cu ei. Am intalnit de exemplu in loc de "left right slider" denumirea de "balanta" desi la cum arata vizual acel slider, numai cu gandul la o balanta nu te duce, iar pentru "up down slider" denumirea de "scarita" sau ceva de genul asta.
Bine macar ca la button i-au zis buton.
La meniul tools i-au spus "unelte". Cred ca ar fi fost mai distractiv sa ii spuna "scule".
Bine macar ca la button i-au zis buton.
La meniul tools i-au spus "unelte". Cred ca ar fi fost mai distractiv sa ii spuna "scule".
Eu nici pe telefon nu m-am obisnuit cu interfata in romana. In general, am observat ca textele in romana sunt mai lungi, si se folosesc prescurtari care ma deranjeaza. De multe ori nici nu imi dau seama ce vor sa zica, exact ca celebrele traduceri in romana de pe pc.
Vortex Website
Maximum de confort, cu minimum de efort.
Maximum de confort, cu minimum de efort.
Pe telefon cred ca am schimbat de cateva ori pe engleza ori din greseala, ori la inceput ca sa aud cum suna sinteza englezeasca, ori in unele programe care aveau doar interfata in engleza si era mai usor cu sinteza in engleza. Dar in general am vazut ca pe telefon nu se anunta atat de multi termeni tehnici cum sunt denumirile controalelor in comparatie cu Windows.
Adica chestii de genul tree view, list view, list box, menu item, radio button, check box etc, ci se spune in general doar eticheta respectivului control. Am auzit de buton, dar cum asta suna aproape ca in engleza, e OK.
Pe Symbian foloseam sinteza in engleza, dar acolo apareau controale ca menu, list box, se spunea numarul elementelor din lista, cam ca pe computer.
Adica chestii de genul tree view, list view, list box, menu item, radio button, check box etc, ci se spune in general doar eticheta respectivului control. Am auzit de buton, dar cum asta suna aproape ca in engleza, e OK.
Pe Symbian foloseam sinteza in engleza, dar acolo apareau controale ca menu, list box, se spunea numarul elementelor din lista, cam ca pe computer.
-
Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Da, se anunta parca mai putine informatii, totusi la Android anunta check-box, buton radio, buton simplu, casuta combinata.
Screen reader-ul Spiel, cand l-am incercat pe Android 2.3 spunea si numarul de itemi dintr-o lista.
Probabil ca lucrurile fiind mai simple pe telefon si din punctul de vedere al interfetei, se considera ca nu e nevoie de atat de multe detalii.
Se intampla desc ca spune un simplu text, ca si cum ar fi un TextView banal, dar totusi incerc un dublu tap pe el sa vad daca nu face ceva.
Screen reader-ul Spiel, cand l-am incercat pe Android 2.3 spunea si numarul de itemi dintr-o lista.
Probabil ca lucrurile fiind mai simple pe telefon si din punctul de vedere al interfetei, se considera ca nu e nevoie de atat de multe detalii.
Se intampla desc ca spune un simplu text, ca si cum ar fi un TextView banal, dar totusi incerc un dublu tap pe el sa vad daca nu face ceva.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
-
Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Android Studio accesibil
La semnalarea lui Campus care mi-a trimis un articol de pe site-ul Android Developers, am aflat că s-a lucrat la accesibilizarea IDE-ului Android Studio.
Informaţiile despre accesibilitatea Android Studio sunt la link-ul următor:
https://developer.android.com/studio/in ... ility.html
Am instalat aşadar şi eu Android Studio şi după ce am activat Java Acces Bridge şi am făcut verificările menţionate de ei în pagina de mai sus, am ajuns să import un proiect creat cu Eclipse ADT şi să citesc cod, să găsesc erorile etc.
Până la urmă se poate lucra se pare cu JAWS sau NVDA, Window-Eyes e exclus, aşa spun ei acolo.
Deocamdată, fiind obişnuit cu Eclipse şi elementele lui grafice native din sistemul de operare, lucrul cu Android Studio mi se pare greoi; este cu interfaţă Java, iar JAWS afişează totul în virtual buffer.
Până la urmă cam trebuie trecut pe Android Studio unde sunt anumite avantaje precum utilizarea Gradle, în Eclipse devine o mare bătaie de cap să foloseşti SDK-uri gen Facebook care devin din ce în ce mai greu de importat, trebuind utilizate tot felul de work-around-uri.
Informaţiile despre accesibilitatea Android Studio sunt la link-ul următor:
https://developer.android.com/studio/in ... ility.html
Am instalat aşadar şi eu Android Studio şi după ce am activat Java Acces Bridge şi am făcut verificările menţionate de ei în pagina de mai sus, am ajuns să import un proiect creat cu Eclipse ADT şi să citesc cod, să găsesc erorile etc.
Până la urmă se poate lucra se pare cu JAWS sau NVDA, Window-Eyes e exclus, aşa spun ei acolo.
Deocamdată, fiind obişnuit cu Eclipse şi elementele lui grafice native din sistemul de operare, lucrul cu Android Studio mi se pare greoi; este cu interfaţă Java, iar JAWS afişează totul în virtual buffer.
Până la urmă cam trebuie trecut pe Android Studio unde sunt anumite avantaje precum utilizarea Gradle, în Eclipse devine o mare bătaie de cap să foloseşti SDK-uri gen Facebook care devin din ce în ce mai greu de importat, trebuind utilizate tot felul de work-around-uri.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
Re: Android Studio accesibil
Din pacate pentru noi, vazatorii prefera flexibilitatea si usurinta, nu standardizarea si folosirea unor elemente clasice.
Pentru noi evident ca sunt mai bune interfetele SWT, fiindca ele folosesc controale native acolo unde este posibil, si nu SWING, care au nevoie de Java Access Bridge, care modifica comportamentul interfetelor si de aceea nici nu este activata in mod implicit, si care raspunde mai lent la comenzi, plus ca nu ofera la fel de multe informatii ca si controalele native.
Partea nasoala este ca cei de la FreedomScientific au inceput de multa vreme sa ofere informatia intr-un mod accesibil doar folosind cursorul virtual chiar si pentru obiecte ceva mai standard, cum sunt cele din ribbon, asa ca nu prea cred ca ne putem astepta sa rescrie suportul pentru clasele SWING si sa il putem accesa la fel cum accesam controalele native. Si poate ca SWING+Java Access Bridge nici nu ofera facilitatile necesare pentru a putea face asa ceva.
Iar viitorul nu suna prea bine. Probabil ca inainte de a alege clasele SWING pentru a crea programul, cei de la Google s-au gandit si sa il creeze folosind HTML + JavaScript, fiindca ei vor ca totul sa se mute pe web, asta fiind in avantajul lor.
Doar ca pentru moment asta este prea dificil. Insa HTML + JavaScript evolueaza mult mai rapid decat alte interfete grafice. De fapt, cred ca este singura solutie de interfata grafica care evolueaza. Celelalte cam stagneaza.
Google ofera acum aplicatii web de genul Google Docs si Google Sheets, un fel de MS Word si MS Excel in browser, care sunt din ce in ce mai bune, sunt accesibile si pentru JAWS, si am citit o discutie si despre nu stiu ce editor pentru programare, dar nu am bagat-o in seama fiindca nu m-a interesat.
Incet incet vom fi obligati sa ne stocam fisierele in cloud fiindca va fi mai simplu sa le accesam pe dispozitivele mobile si cu editoarele de text si cu alte aplicatii web, ne va fi mai simplu sa publicam programele folosind solutiile oferite de firme mari ca Google si Apple...
Pentru noi evident ca sunt mai bune interfetele SWT, fiindca ele folosesc controale native acolo unde este posibil, si nu SWING, care au nevoie de Java Access Bridge, care modifica comportamentul interfetelor si de aceea nici nu este activata in mod implicit, si care raspunde mai lent la comenzi, plus ca nu ofera la fel de multe informatii ca si controalele native.
Partea nasoala este ca cei de la FreedomScientific au inceput de multa vreme sa ofere informatia intr-un mod accesibil doar folosind cursorul virtual chiar si pentru obiecte ceva mai standard, cum sunt cele din ribbon, asa ca nu prea cred ca ne putem astepta sa rescrie suportul pentru clasele SWING si sa il putem accesa la fel cum accesam controalele native. Si poate ca SWING+Java Access Bridge nici nu ofera facilitatile necesare pentru a putea face asa ceva.
Iar viitorul nu suna prea bine. Probabil ca inainte de a alege clasele SWING pentru a crea programul, cei de la Google s-au gandit si sa il creeze folosind HTML + JavaScript, fiindca ei vor ca totul sa se mute pe web, asta fiind in avantajul lor.
Doar ca pentru moment asta este prea dificil. Insa HTML + JavaScript evolueaza mult mai rapid decat alte interfete grafice. De fapt, cred ca este singura solutie de interfata grafica care evolueaza. Celelalte cam stagneaza.
Google ofera acum aplicatii web de genul Google Docs si Google Sheets, un fel de MS Word si MS Excel in browser, care sunt din ce in ce mai bune, sunt accesibile si pentru JAWS, si am citit o discutie si despre nu stiu ce editor pentru programare, dar nu am bagat-o in seama fiindca nu m-a interesat.
Incet incet vom fi obligati sa ne stocam fisierele in cloud fiindca va fi mai simplu sa le accesam pe dispozitivele mobile si cu editoarele de text si cu alte aplicatii web, ne va fi mai simplu sa publicam programele folosind solutiile oferite de firme mari ca Google si Apple...
Intr-adevar Android Studio este un IDE foarte complex. Eu in fiecare zi gasesc tot felul de optiuni de care nici nu stiam ca exista. De exemplu exista o optiune care analizeaza marimea fisierelor dintr-un pachet instalabil apk si te ajuta sa reduci marimea pachetului micsorand, de exemplu, elementele grafice care sunt prea mari (aici in afara de rezolutie la marimea fisierului respectiv mai conteaza si dpi-ul). De asemenea exista monitoare foarte complexe care iti arata in timp real parametrii din telefon precum utilizrea memoriei, a chipsetului grafic, a consumului de retea si a procesorului in timpul rularii aplicatiei.
Din cate stiu eu Android Studio nu e creat de google ci e adaptat dupa IntelIJ IDEA , un ide de java si el destul de complex.
Cred ca multe din problemele de accesibilitate apar si din felul in care e construit jaws. Cei de la google recomanda chiar in articolul respectiv nvda ca cititor de ecran pentru lucrul cu android studio. Dar pentru voi, cei care ati lucrat deja de o viata cu jaws e de inteles ca aveti unele dificultati de adaptare.
Pe de alta parte e mare pacat ca nu exista inca un cititor de ecran utilizabil pe linux. Profitand de resturile mele de vedere, cate mai sunt, eu folosesc deja de un an exclusiv linux pe laptopul personal si pot spune ca deja ma simt mult mai confortabil decat in windows. Aici chiar am sentimentul ca sunt in deplin control al calculatorului ceea ce in windows e din ce in ce mai putin valabil mai ales de la politica de update fortat introdusa cu windows 10.
Folosesc si un plugin de compiz care, desi e putin instabil, imi ofera posibilitatea sa fac zoom in timp real in desktop si astfel imi maresc intotdeauna cat vreau eu elementele afisate pe ecran ceea ce pe windows nici un magnifier nu face la fel de performant.
In plus, pe acelasi hardware. Android studio ruleaza sensibil mai bine sub linux. Acelasi lucru il pot spune si despre alte programe bazate pe java cum e netbeans, de exemplu.
Din cate stiu eu Android Studio nu e creat de google ci e adaptat dupa IntelIJ IDEA , un ide de java si el destul de complex.
Cred ca multe din problemele de accesibilitate apar si din felul in care e construit jaws. Cei de la google recomanda chiar in articolul respectiv nvda ca cititor de ecran pentru lucrul cu android studio. Dar pentru voi, cei care ati lucrat deja de o viata cu jaws e de inteles ca aveti unele dificultati de adaptare.
Pe de alta parte e mare pacat ca nu exista inca un cititor de ecran utilizabil pe linux. Profitand de resturile mele de vedere, cate mai sunt, eu folosesc deja de un an exclusiv linux pe laptopul personal si pot spune ca deja ma simt mult mai confortabil decat in windows. Aici chiar am sentimentul ca sunt in deplin control al calculatorului ceea ce in windows e din ce in ce mai putin valabil mai ales de la politica de update fortat introdusa cu windows 10.
Folosesc si un plugin de compiz care, desi e putin instabil, imi ofera posibilitatea sa fac zoom in timp real in desktop si astfel imi maresc intotdeauna cat vreau eu elementele afisate pe ecran ceea ce pe windows nici un magnifier nu face la fel de performant.
In plus, pe acelasi hardware. Android studio ruleaza sensibil mai bine sub linux. Acelasi lucru il pot spune si despre alte programe bazate pe java cum e netbeans, de exemplu.
Toate cele bune!
Campus
Campus