Languages

 

Original Source- Dan’s Web Tips: Languages

Author- Daniel R. Tobias

[email protected]

 

 

Idiomes

Vegeu també les traduccions en alemany i serbocroat (fet per altres persones en el seu propi lloc web, amb el meu permís).

Tot i que “World Wide” és part del nom de la Web, mai ha estat pensat per ser un mitjà només en anglès. Podem utilitzar qualsevol idioma en els nostres llocs web, i s’han afegit diverses facilitats als estàndards de la Web que ens permeten indicar quines llengües estem utilitzant en benefici d’indexadors i traductors, i fins i tot per oferir intel·ligentment diferents versions idiomàtiques de les nostres pàgines per tal de satisfer les preferències dels nostres usuaris. Aquesta pàgina descriu algunes d’aquestes tècniques.

Les “llengües” que tenim en compte aquí són llengües humanes com el espanyol i el xinès mandarí, no llenguatges informàtics com l’HTML i el JavaScript. Els idiomes informàtics que utilitzem en el nostre lloc web són també una elecció important, però aquest no és l’objecte d’aquest article!

Indicant l’idioma

L’HTML ens dona la capacitat de marcar un document, o una part d’aquest, indicant en quin idioma està escrit. Això es fa amb l’atribut LANG, que es pot posar en gairebé qualsevol etiqueta.

Per indicar que tota la pàgina està escrita en anglès, hauríem de posar això en l’etiqueta HTML al principi:

<HTML lang=”en”>

El valor de l’atribut és el codi per a l’idioma en el qual el document està escrit. La majoria de les llengües més comunes del món tenen codis de dues lletres (definits en la norma ISO 639-1), i una llista més gran (que inclou llengües “mortes”) tenen codis de tres lletres (en ISO 639-2). RFC 3066 afirma que el codi de dues lletres ha de ser utilitzat en preferència al codi de tres lletres quan n’existeixi un, de manera que normalment només trobarem codis de dues lletres en els atributs del llenguatge Web. Aquí i aquí trobareu algunes referències als codis de dues lletres.

Per tal d’especificar un dialecte concret, es pot afegir un sufix al codi d’idioma amb un guió i un codi addicional, sovint un codi de país. Quan es fa això, tradicionalment el codi de l’idioma  base es dona en minúscula i el codi del país en el sufix en majúscules (tot i que això no és necessari, ja que els codis no distingeixen entre minúscules i majúscules). Així, s’indica l’anglès americà amb en-US i l’anglès britànic amb en-GB. (Fixeu-vos que GB és el codi de país adequat per al Regne Unit, no UK, tot i que .uk és el sufix de domini que s’utilitza allà. En altres casos, però, el codi de país estàndard concorda amb el domini de codi de país per a un determinat país.) es-MX és el codi per l’espanyol mexicà. Els dialectes no nacionalses poden indicar amb el seu nom complet  — en-cockney per al dialecte cockney de l’anglès.

També podem indicar que porcions més petites d’un document estan escrites en un idioma en particular posant un atribut lang en l’etiqueta d’obertura d’un element. Per exemple, podem indicar l’idioma d’una cita posant un atribut lang en l’etiqueta blockquote . Si cap element simple cobreix la secció del document que volem marcar d’aquesta manera, podem utilitzar un element DIV  o SPAN per a aquest propòsit. (DIV és un element de nivell de blocs que contenir paràgrafs sencers i altres elements de bloc; SPAN  és un element de nivell de caràcter que pot ser contingut dins un paràgraf o un altre bloc). Per exemple:

<BLOCKQUOTE lang=”en”>How are you? Or, as I’d say in Spanish, “<SPAN lang=”es”>¿Como estás, o como diga en inglés, ‘<SPAN lang=”en”>How are you?</SPAN>’?</SPAN>”</BLOCKQUOTE>

Això apareix així en el teu navegador:

How are you? Or, as I’d say in Spanish, “¿Como estás, o como diga en inglés, ‘How are you?’?”

Probablement no hi ha cap efecte visible d’aquests diversos atributs d’idioma, tot i que en alguns casos un navegador farà ús d’ells per variar la presentació de manera que s’adapti a un idioma en particular, com utilitzar una font diferent per defecte. No obstant això, en un navegador gràfic normal, quan es mostren llengües com l’anglès i l‘espanyol que són expressables en caràcters estàndard ASCII i Latin-1, hi ha poca necessitat de tals coses. (Per altres llengües, que utilitzen conjunts de caràcters més “exòtics”, Netscape 7 i Mozilla sí que varien el tipus de lletra segons l’atribut lang). En qualsevol cas, la informació sobre en quin idioma està escrita cada secció del text és allà per ser utilitzada per qualsevol agent d’usuari que tingui un ús per a això, com un navegador que parli que pugui ajustar la seva pronunciació en conseqüència, o un robot d’indexació que construeix els diferents índexs de  material en diferents idiomes. (De fet, el navegador que parla de l’IBM Home Page Reader reconeix atributs “lang” i això afecta la manera com aquest pronuncia el text). Les directrius d’accessibilitat de W3C requereixen que marquem fidelment l’idioma de tot el text en el nostre lloc web.

Tingueu en compte que elements amb atributs de llenguatge poden estar col·locats en una profunditat arbitrària. L’element més profund que envolta un determinat segment de text és sempre el que regula en quin idioma està escrit. Així, en l’exemple anterior, la cita en conjunt està escrita en anglès, però té una secció en espanyol que, al seu torn, conté un apartat que està escrit en anglès.

 

Una altra manera d’indicar l’idioma del document

Els atributs anteriors formen part de l’HTML. No obstant això, una altra capa de les normes i protocols pels quals els documents Web arriben als usuaris és l’HTTP (HyperText Transfer Protocol), el protocol de transferència d’hipertext. Aquest, també, té una manera d’especificar en quin idioma està escrit el document. Si fas que el servidor enviï aquest encapçalament:

Content-Language: en-US

això indicarà que la pàgina està escrita en anglès americà. Més endavant, en la secció sobre negociació de l’idioma, parlo del protocol HTTP i de com configurar el teu servidor per a ajustos relacionats amb la llengua. Si no estàs fent negociació de l’idioma del contingut, probablement no cal que toquis la configuració del protocol HTTP; els atributs de llenguatge d’HTML són més fàcils i més flexibles d’utilitzar (atès que es poden marcar seccions d’una pàgina, no només la pàgina com un tot).

 

Traductors en línia

Un tipus d’agent d’usuari que podria fer gran ús d’aquests atributs és un traductor en línia, que agafa una pàgina web i tradueix el seu text a un idioma diferent. Malauradament, els que existeixen actualment no semblen fer gaire ús d’aquests atributs. El traductor AltaVista Babelfish, que era el més popular en el moment que això va ser escrit originalment (però ara és difunt; vegeu-ne aquí un “clon” més modern o useu “http://translate.google.com/”> Google Translator), no sembla preocupar-se gens per aquests atributs, i en canvi confia en l’usuari per a que li indiqui, mitjançant un menú desplegable, en quin idioma està escrit el document font, i llavors confiant en això sense tenir en compte el que la pàgina realment indica. Uns pocs altres traductors en línia fan un ús mínim dels atributs lang, fent cas de l’element HTML d’alt nivell que indica l’idioma del document sencer, però sense prestar atenció a cap altre atribut lang  en qualsevol altre lloc en el document. Això produeix situacions estranyes quan una pàgina està escrita majoritàriament en un idioma però conté citacions en altres llengües; els traductors intentaran traduir les citacions com si estiguessin escrites en l’idioma principal (per exemple, en una cita espanyola dins una pàgina en anglès, veurà la paraula “sin”, que en espanyol vol dir “sense”, com la paraula anglesa “sin” i la traduirà com “pecat”.) Aquest és un cas on un traductor més intel·ligent podria tenir en compte atributs que denotin l’idioma de les parts del document i adonar-se que aquestes seccions s’han de deixar sense traduir o ser traduïdes en un idioma d’origen diferent.

Aquesta situació sembla ser un dels molts dilemes de “l’ou o la gallina” que afecten la introducció de qualsevol element i atribut lògic i, estructural en HTML; els desenvolupadors de programes no es molesten a implementar el suport per a ells perquè pocs autors web l’estan utilitzant, i els creadors de webs no es molesten a utilitzar-los perquè pocs programes fan res amb ells. Aquest tipus de nus gordià no sembla afectar millores “presentacionalistes” que pretenen crear efectes visuals “genials”, com els que van ser introduïts moltes vegades per Netscape i Microsoft amb el pas dels anys; aquestes coses semblen tenir una gran multitud d’admiradors d’allò que “enlluerna” disposats a començar a utilitzar-los fins i tot mentre el suport del navegador és encara dubtós (col·locant una icona de “Es veu millor amb l’última versió del meu navegador favorit” a la portada, convidant a la gent a acceptar la millora). O, almenys aquest va ser el cas en els primers anys de la popularitat massiva de la Web; les coses sembla que han madurat i s’han estabilitzat molt més ara. Però qualsevol millora que afecti l’estructura lògica subjacent, darrere de l’escenari, sense efecte visual notable, no susciten el mateix interès entre els dissenyadors de webs o desenvolupadors de programari, així que aquestes coses tarden molt més a ser implementades.

Per trencar aquest cicle, soc partidari de que els autors web facin tot el possible per utilitzar aquest tipus d’etiquetatge lògic; això no farà mal al processament de les seves pàgines i encoratjarà a futures generacions d’autors d’agents d’usuari a finalment fer alguna cosa útil amb les etiquetes i atributs en qüestió.

 

Etiquetant enllaços

A més d’indicar l’idioma de seccions de text en la nostra pròpia pàgina, també podem indicar l’idioma d’altres documents als quals enllaça. Aquest sistema utilitza l’atribut hreflang. Per exemple:

<A hreflang=”es” lang=”en” href=”spanish.html”>A page in Spanish</A>

Tingueu en compte que l’element anterior té tant un atribut lang com un atribut hreflang . L’atribut lang indica l’idioma del text dins de l’element, en aquest cas “Una pàgina en espanyol”, que està en anglès, com s’indica. L’atribut hreflang  indica que la pàgina que a la qual s’enllaça està escrita en espanyol.

Mentre que no hi ha gaire suport de l’agent d’usuari per a aquest atribut, el navegador Mozilla sí que mostra l’idioma del document de destinació a la finestra d’informació que podem veure clicant “Propietats” en el menú contextual quan fem clic en un enllaç.

 

Negociació de l’idioma

Ara quelcom més complex. Pot ser que tinguem versions d’una mateixa pàgina en diversos idiomes. Existeix un mecanisme per poder oferir als usuaris el seu idioma preferit, tot des de la mateixa adreça URL. Aquest mecanisme, anomenat “negociació de l’idioma del contingut”, ha estat present en el protocol HTTP durant anys, però rarament és utilitzat. En lloc d’això els desenvolupadors de pàgines web han triat aquesta com una de les rodes que van reinventant, de diverses maneres que són generalment inferiors al sistema original. Així, els llocs web estan plens de dispositius complicats amb galetes i JavaScript que intenten dirigir els usuaris cap al seu idioma preferit (possiblement fracassant a portar-los a qualsevol lloc si les galetes o JavaScript estan desactivats), o intenten redirigir l’usuari basant-se en quin país el servidor pensa que es troben (una cosa molt poc fiable de determinar, ja que els usuaris podrien estar connectats a través d’un ISP en un país diferent del de la seva ubicació real, i de tota manera la ubicació física tampoc no determina amb certesa quina llengua parlen).

Hi ha una manera millor de fer-ho. Els navegadors ofereixen com a part de les seves configuracions la possibilitat d’especificar quins idiomes vol utilitzar l’usuari, i en ordre de preferència. Això s’envia com a part de la sol·licitud HTTP per a qualsevol pàgina web que l’usuari recuperi i el servidor pot utilitzar-ho per triar quina versió envia.

 

Configurant els ajustos d’idioma del navegador

En general, la preferència del navegador és en forma d’una llista de selecció d’idiomes que l’usuari pot triar un a un, formant una llista ordenada. A Mozilla i Netscape això es pot trobar en l’element “Preferències” del menú “Editar”; dins d’aquest trobem l’opció “Idiomes” dins l’apartat “Navegador”. A Opera, és l’element “Preferències” del menú “Arxiu”, dins d’”Idiomes”. A MSIE, és l’element “Opcions d’Internet” del menú “Eines”; cliqueu l’opció “Idiomes” a la part inferior de la pestanya “General”.

Lamentablement, cap d’aquests navegadors fan una bona feina a l’hora d’explicar a l’usuari com configurar les preferències d’idioma. En particular, la relació dels idiomes genèrics (es = espanyol) i varietats d’idioma específics (es-MX = espanyol de Mèxic) no s’explica. Si un usuari selecciona una varietat específica d’un idioma (una variant d’un país, per exemple), però també entén d’altres dialectes de l’idioma, llavors també hauria de seleccionar la versió genèrica per assegurar-se que les pàgines de totes les varietats de l’idioma que ha escollit estiguin disponibles, no només les del país en particular que l’usuari prefereixi més. Per exemple, algú que entén l’espanyol i l’anglès i prefereix la varietat mexicana de l’espanyol i la varietat dels EUA de l’anglès (però també accepta altres varietats) pot establir aquest ordre de preferència:

es-MX, es, en-US, en

En aquest cas, si el document sol·licitat està disponible en espanyol de Mèxic, es servirà en preferència a totes les altres versions. No obstant això, si aquesta versió no està disponible, però n’hi ha una en espanyol veneçolà (es-VE), llavors serà tractada com una coincidència amb l’entrada d’espanyol genèric i se servirà amb preferència a d’altres llengües. Si no hi ha una versió en espanyol disponible, llavors es comprovarà primer si hi ha una versió en anglès americà, però si no n’hi ha llavors es servirà una versió en anglès britànic (en-GB) o una versió en anglès genèric (en). Tingueu en compte que és important posar la versió genèrica en la vostra llista després de qualsevol variant específica del mateix idioma, si no la versió genèrica coincidirà amb qualsevol subtipus d’aquest idioma, i no necessàriament el subtipus que prefereixis més. Si un lloc web resulta tenir una versió en anglès dels EUA i una versió en anglès britànic, l’element en de la llista de preferència coincidirà amb els dos (i la preferència entre els dos es resoldrà aleatòriament o per un ajust de “nivell de qualitat” en la configuració del servidor en la qual el webmaster ha decidit quina versió és preferible quan l’usuari final no té preferència), però si l’element en-US es troba primer en la teva llista, expressarà inequívocament la teva preferència per l’anglès americà.

No obstant això, si la teva llista de preferències omet les versions genèriques:

es-MX, en-US

llavors li estàs dient al servidor que només vols espanyol de Mèxic o l’anglès dels EUA, cap altra varietat. Si el lloc té versions en espanyol panameny i anglès australià, cap coincidiria amb la teva llista de preferència i llavors estaries a mercè del que el servidor decideixi fer en casos on cap idioma coincideixi. (A continuació veureu algunes pistes sobre com un webmaster pot tractar aquests casos.) És probable que no acabis amb el teu idioma preferit en aquest cas, així que hauries d’evitar-ho. Lamentablement, però, els principals navegadors no ens adverteixen d’això, i alguns d’ells alegrement acceptaran aquestes preferències defectuoses sense queixa. (Hi ha casos rars on algú en realitat podria tenir una preferència d’aquest tipus, especialment en el cas de llengües amb dialectes mútuament incomprensibles, però en casos més comuns un usuari seria millor servit si s’inclogués el genèric a més de les varietats específiques).

Opera evita aquest problema, en general, incloent només idiomes genèrics i no varietats específiques (amb algunes excepcions, com el xinès, per al qual s’inclouen diverses varietats); això elimina la capacitat de l’usuari d’entrar en un “bloqueig” pel fet de triar només una varietat sense el seu principal genèric, però elimina també la capacitat d’expressar una preferència més acurada pel que fa als dialectes. D’altra banda, MSIE inclou sobretot varietats específiques en la seva llista, i en el cas de moltes llengües la varietat genèrica no es troba encara disponible (tot i que hi ha la possibilitat d’afegir més idiomes segons la pròpia elecció). Això fa que sigui difícil per als usuaris configurar els seus ajustos d’idioma correctament, amb versions específiques i genèriques, fins i tot si són conscients que ho han de fer així.

La millor manera de gestionar això, en la meva opinió, seria incloure tant els genèrics com els específics (com fan Mozilla i Netscape) però afegir un missatge d’advertiment si l’usuari estableix una preferència que omet els genèrics (cosa que per desgràcia aquests navegadors no fan).

Els navegadors normalment es configuren per defecte amb les preferències d’idioma que coincideixin amb la llengua d’interfície d’usuari del navegador. Si comprem un ordinador que ha estat configurat específicament per a un país determinat, qualsevol navegador preinstal·lat estarà segurament configurat en l’idioma dominant d’aquest país. Si hem comprat l’ordinador en un altre país (per exemple, els mexicans sovint compren els seus ordinadors als Estats Units) i no ha estat configurat per un distribuïdor local, pot ser que tingui per defecte un idioma estranger. Si descarreguem un navegador, pot ser que tinguem l’opció de descarregar versions en diferents idiomes, o canviar un paràmetre de la configuració d’idioma durant el procés d’instal·lació. Atès que la majoria dels usuaris tendeixen a deixar el seu programari en la configuració inicial per defecte, això significa que alguns navegadors, però no tots, tenen ben configurades les preferències d’idioma dels seus usuaris. A més, a causa del fracàs dels creadors de navegadors a l’hora de tractar adequadament el problema del genèric vs. específic, un munt de navegadors estan configurats per acceptar només una variant particular d’un idioma i no l’idioma en general — en-US enlloc de en.

A causa d’aquestes qüestions, alguns webmasters es pregunten si l’ús de la negociació de l’idioma és una bona idea, i això pot portar a debats filosòfics sobre si és millor intentar educar els usuaris sobre com treure profit de les característiques dels seus navegadors, o si els desenvolupadors haurien de renunciar-hi i tan sols complaure l’assumit nivell d’ignorància de l’usuari. En aquests debats normalment em poso al costat dels qui volen utilitzar les característiques correctament i tractar d’ensenyar a altres a fer-ho; l’altra ruta condueix a l’embrutiment d’Internet i a la perpètua reinvenció de les rodes en versions inferiors.

 

Preparant els llocs web per a la negociació de l’idioma

Exactament com configurem el nostre lloc per a utilitzar aquesta característica dependrà en el programari de servidor que s’estigui utilitzant. Ja que Apache és el servidor web més popular en l’actualitat, vaig a descriure com fer-ho amb aquest sistema, però hi ha mètodes d’aconseguir això també amb d’altres programaris.

 

Crear documents

En primer lloc, hem de crear diferents versions idiomàtiques dels nostres documents amb una nomenclatura coherent. De fet, és possible configurar la negociació de l’idioma sense importar quin nom donem a les diferents versions, però és més fàcil fer-ho donant als arxius extensions basades en l’idioma en el qual estan, a més de qualsevol extensió que ja hi sigui per indicar el tipus de dades. Per exemple, si anteriorment teníem només una versió d’un sol idioma d’una pàgina, anomenada mypage.html, i ara volem negociar entre les versions en anglès i espanyol d’aquesta, podem anomenar-les mypage.html.en i mypage.html.es. (Més tard discutiré sobre la qüestió de si posar el sufix d’idioma abans o després de l’altra extensió de fitxer com .html, i com això afecta com accedim a les pàgines. Per ara, suposarem que el sufix d’idioma es posa al darrere).

 

Ajustar la configuració

Ara necessitem dir-li al servidor què signifiquen els sufixos i que tenim la intenció d’utilitzar-los per a la negociació. Una manera de fer això és amb un arxiu de .htaccess (el nom del fitxer és exactament això, .htaccess, amb el punt com a primera lletra, tan antinatural com pugui semblar a usuaris de MS-Windows més acostumats a l’esquema filename.ext; malauradament, algun programari de PC fa difícil crear arxius amb aquests noms, mentre tracta de transformar-los en noms d’arxiu amb un estil més “familiar”), amb les línies següents:

Options +MultiViews
AddLanguage en-US .en
AddLanguage es-MX .es
LanguagePriority en-US es-MX

La primera línia li diu a Apache que permeti l’ús de la modalitat “MultiViews”, on es pot triar entre les versions alternatives d’un document en lloc de servir només el mateix arxiu per a tothom. Les dues línies següents li indiquen que .en representa un document en anglès (varietat dels EUA), i .es representa un document en espanyol (varietat mexicana). (Posa els idiomes que triïs aquí; pots tenir tantes llengües diferents com vulguis, amb una extensió diferent per a cadascuna que pot, però no necessàriament cal, que coincideixi amb el codi d’idioma – en general, les persones que utilitzen el polonès com un dels idiomes admesos utilitza quelcom diferent al codi d’idioma .pl perquè aquest s’usa normalment a la Web com a extensió de scripts de Perl). La línia final suggereix l’ordre de prioritat per a les diferents llengües en casos on l’agent d’usuari no expressa la preferència; aquí, he fet de l’anglès la primera opció. Probablement voldràs utilitzar qualsevol de la llengües que penses que en general té la més alta qualitat en el teu lloc web, potser l’idioma en el qual escrius i del qual els altres possiblement pot ser que es perdin alguna cosa en la traducció.

 

Els arxius.htaccess es poden col·locar en qualsevol subdirectori del lloc web i són aplicables a tot el contingut en aquest directori i en els directoris inferiors. Per tant, hauries de posar el teu arxiu en el directori arrel del vostre lloc web (el directori superior on les dades públiques de la Web s’emmagatzemen, normalment on es troba la portada principal) si voleu que s’apliqui a la totalitat del lloc web, o en un subdirectori si utilitzeu només aquestes característiques en un subconjunt del vostre lloc i no voleu que interfereixin amb la resta del seu contingut.

Ara intenta accedir-hi!

Ara que heu configurat el fitxer.htaccess i posat en línia els fitxers mypage.html.en i mypage.html.es, podeu provar d’accedir a la URL http://yoursite.example/mypage.html (on yoursite.example és substituït amb el nom del vostre domini i qualsevol informació de ruta necessària per arribar on està la vostra pàgina). Si ho has fet tot correctament, hauries d’haver acabat amb la versió en anglès o en espanyol de la pàgina segons la teva configuració d’idioma.

 

Ups!… Encara tinc la versió vella de la pàgina!

Si, en canvi, acabes amb la versió antiga de mypage.html d’abans de començar a intentar afegir la negociació d’idioma, això vol dir que has deixat aquell arxiu al costat dels nous arxius mypage.html.en i mypage.html.es. Quan un usuari intenta accedir a la URL que acaba en mypage.html, Apache primer busca un arxiu que concordi exactament amb aquest nom. Si en troba un no intentar els “MultiViews”; l’arxiu que es troba immediatament és el que se serveix. Per tant, hauries de suprimir l’arxiu vell per permetre Apache trobar els arxius que realment vols que et serveixi. Si no es troba cap arxiu coincident, Apache procedeix a la fase de negociació, cercant tots els arxius que són anomenats mypage.html amb extensions addicionals després d’això, i veient quin d’ells millor coincideix amb les llengües acceptables (o, en aquest cas, formats de dades; la negociació pot ser utilitzada, en teoria almenys, per servir  a HTML, PDF, i les versions de MS-Word, per exemple, d’un document basat en les preferències de l’usuari, tot i que els navegadors més populars no fan realment ús d’aquesta capacitat avui en dia). Si l’anglès és la primera opció d’idioma de l’usuari, mypage.html.en coincidirà i serà servit.

De fet, la part .html del nom de fitxer no cal que s’inclogui en la URL quan MultiViews està habilitat, ja que aquesta part també és objecte de negociació, i tots els navegadors habituals inclouen HTML com un dels seus tipus de contingut acceptats. Una sol·licitud de l’URL que acabi en mypage (sense una extensió donada) farà que mypage.html.en coincideixi, ja que Apache associa .html amb el tipus text/html MIME, i tu hauràs associat .en amb l’idioma anglès.

Alguns desenvolupadors afavoreixen l’ús d’URL sense extensió d’aquesta manera, ja que són més curtes, més netes i més “a prova de futur” (podràs canviar el format de les dades o el llenguatge de programació en el futur sense canviar l’URL). Altres les troben una mica antinaturals, ja que estan acostumats a que les URLs tinguin extensions d’arxiu al final quan no són subdirectoris acabats en barra inclinada. Si afegeixes la negociació MultiViews a un lloc ja existent, probablement ja utilitzes enllaços a URLs que acaben en .html (o d’altres extensions) i pot ser que no vulguis canviar-los. Així que hi ha pros i contres per les dues maneres de fer les coses, però que totes dues funcionen. Un avantatge de treure l’extensió de l’URL és que llavors pots afegir múltiples extensions en qualsevol ordre amb la finalitat de tipus de contingut, idioma i altre negociació – – .html.en. i .en.html funcionaran idènticament. Si els URL acaben en .html, els teus noms d’arxiu no haurien d’incloure d’altres extensions abans d’això o no coincidiran correctament.

 

Però què passa si l’usuari no inclou cap dels dos idiomes a la sol·licitud?

Un problema que pot sorgir és el de trobar-te amb sol·licituds que no indiquen com a acceptable qualsevol dels idiomes de la pàgina. Si un usuari envia la seqüència d’acceptació fr-CA, fr, de, que significa que les seves llengües preferents són el francès canadenc, el francès genèric i l’alemany genèric, llavors ni el teu espanyol ni el teu anglès hi coincidiran. Tècnicament, res en el teu lloc web és acceptable per a l’usuari, i amb la configuració anterior l’usuari rebrà una pàgina d’error dient-ho. (Malauradament, la pàgina d’error és generalment en anglès, tot i que l’usuari ha indicat que aquest no és un idioma acceptable!) Si bé això és tècnicament acurat, la majoria dels webmasters preferirien que no passés; és una pàgina lletja i difícil d’entendre que comença dient “Not Acceptable”, fent pensar a l’usuari que ha fet alguna cosa malament. Així, la majoria dels webmasters preferiria més aviat que es servís alguna versió del seu contingut real, fins i tot si es troba en un idioma que l’usuari no entén. Aquesta necessitat es fa més urgent a causa de l’existència de navegadors mal configurats que no envien seqüències d’idiomes acceptats que coincideixin amb les veritables preferències dels seus usuaris. Si, per exemple, un navegador envia una seqüència que exclou les versions genèriques dels idiomes preferits, com en-GB, es-VE, llavors les versions en anglès americà i espanyol mexicà no coincidiran i l’usuari rebrà una pàgina d’error, un desafortunat gir dels esdeveniments.

Afortunadament, hi ha una manera de solucionar-ho. Si incloeu una versió del fitxer amb cap codi d’idioma, aquest serà servit quan cap de les versions amb codi d’idioma coincideixin. Has de fer això amb cura, però. Ja hem vist que si deixes un senzill arxiu mypage.html al costat de mypage.html.en, etc., aleshores aquest serà servit amb preferència als altres arxius en resposta a una sol·licitud per a mypage.html Si utilitza la versió de l’URL sense extensions, però, llavors podràs tenir aquests arxius l’un al costat de l’altre, ja que la negociació decideix quina versió s’ha de servir i l’arxiu sense codi d’idioma serà finalment l’escollit si cap llengua hi coincideix. No obstant això, si el teu enllaç sí que té una extensió, encara podràs fer que funcioni, però de forma una mica més complicada. Només cal que creïs un arxiu anomenat mypage.html.html, amb una extensió doble. Aquest no coincidirà amb la sol·licitud Immediatament, permetent que la negociació es porti a terme, però encara coincidirà per defecte després que tot el demés falli.

Fins i tot si utilitzeu enllaços sense extensions i aquests són capaços de sortir-se’n evitant l’ús de l’extensió doble, encara caldrà considerar les pàgines d’índex per defecte per a cada directori. Molt probablement, el teu servidor ha estat configurat per buscar uns quants noms específics com index.html i no un índex sense extensió indexindex.html.en i index.html.html coincidirà amb la negociació, però si hi ha un index.html, aquest coincidirà primer i evitarà la negociació per a l’índex per defecte. Per tant, probablement necessitareu usar “dobles extensions” per a les versions per defecte d’aquests, fins i tot si en tinguéssiu prou amb extensions úniques.

Probablement vols que la versió per defecte sigui idèntica a l’arxiu del vostre idioma preferit. Pots simplement copiar l’altre arxiu amb aquest nou nom, però llavors caldrà recordar actualitzar les dues versions quan hi hagi canvis a la pàgina. Una millor tècnica és fer que el nom per defecte del fitxer sigui un “enllaç” a una de les altres versions de l’arxiu. Si el teu servidor es troba en una plataforma d’estil Unix i tens accés a la shell, podeu utilitzar l’ordre:

 

ln mypage.html.en mypage.html.html

per crear mypage.html.html com un “enllaç” que sempre retorna els mateixos continguts com mypage.html.en, actualitzant-se automàticament cada vegada que aquell arxiu canviï.

La versió més nova d’Apache té algunes ordres més que són utilitzables en arxius .htaccess per especificar el comportament alternatiu per a la negociació d’una manera més simple, però molts llocs web (inclòs el meu) encara són allotjats per proveïdors que utilitzen versions més velles, així que la tècnica anterior per ara encara és necessària.

Un altre problema… i el nyap que l’envolta

Tal com he assenyalat abans, hi ha una tendència preocupant per als navegadors actuals a ser configurats amb una sola variant regional d’un idioma i no la seva variant genèrica — com en-US no acompanyats per en. Tècnicament, això està dient que l’usuari vol només l’anglès americà i no qualsevol altra varietat d’anglès; així, si un document es troba disponible en anglès britànic i francès, i l’idioma per defecte és el francès per a aquest lloc, llavors l’usuari veurà la versió francesa encara que l’anglès sigui probablement el preferit. Em vaig trobar amb aquest problema en un lloc web que vaig construir jo, on les dues versions eren en-US i es-MX i la versió per defecte era en anglès, i em vaig trobar que molts visitants tenien el seu navegador configurat per a certes varietats de l’espanyol com es-PR (espanyol de Puerto Rico) i en canvi veien la versió anglesa quan la versió en espanyol mexicà hauria tingut molt més sentit. De fet això és corresponia perfectament amb els estàndards – que és el que l’usuari de fet demanava – però la finalitat del lloc web en qüestió no és discutir amb els visitants o ensenyar-los a configurar el seu navegador. Per tant, després d’alguns assaigs i errors, vaig inventar-me una mena de “nyap” que donava una millor probabilitat als usuaris de veure el que realment volien en comptes del que en realitat havien demanat. Això no és una cosa que pugui recomanar amb la consciència tranquil·la – va totalment en contra de la meva normal filosofia de desenvolupament Web segons la qual segueixo els estàndards meticulosament i evitant al màxim alimentar algunes mentalitats estúpides que impregnen Internet actualment – però en aquest cas aconseguim millorar l’experiència d’usuari, així que aquí ho teniu en cas que vosaltres també ho vulgueu provar.

El que vaig fer va ser que les versions espanyoles del meu document fessin veure que eren altres versions a més de la varietat mexicana. Mirant els registres del servidor i les configuracions dels navegadors, vaig fer un llistat de les varietats de l’espanyol més usades i els seus codis d’idioma i ho vaig afegir al meu arxiu .htaccess:

AddLanguage es .es1
AddLanguage es-CL .es2
AddLanguage es-CO .es3
AddLanguage es-CR .es4
AddLanguage es-PA .es5
AddLanguage es-PE .es6
AddLanguage es-PR .es7
AddLanguage es-PY .es8
AddLanguage es-SV .es9
AddLanguage es-AR .es10
AddLanguage es-DO .es11
AddLanguage es-US .es12
AddLanguage es-UY .es13
AddLanguage es-BO .es14
AddLanguage es-EC .es15
AddLanguage es-GT .es16
AddLanguage es-HN .es17
AddLanguage es-NI .es18
AddLanguage es-ES .es19
AddLanguage es-VE .es20

Això cobreix una bona part de les variants nacionals, a més de la variant genèrica com a bona pràctica (tot i que no és realment necessari, ja que hauria de coincidir amb qualsevol variant, però el meu període d’assaig i error va mostrar-me que en alguna ocasió feia que la versió espanyola es servís en resposta a una variant que no era a la llista, per alguna raó), associant cadascuna amb una extensió de fitxer diferent, .es1.es2, etc..

A continuació, vaig crear arxius amb “enllaços simbòlics” per a cada pàgina en versió espanyola, amb noms com:

index.html.es1.es2.es3.es4.es5.es6.es7.es8.es9.es10
index.html.es11.es12.es13.es14.es15.es16.es17.es18.es19.es20

Això seria molt pesat de crear a mà, però soc un programador… Només vaig obligar un script de Perl a fer-ho en tot el meu lloc sencer!

El resultat final és que, si el navegador d’un usuari està configurat per a es-PE, el servidor “menteix” i afirma que la versió en espanyol és en realitat d’aquesta varietat. En altres paraules, estic trencant les normes, però el resultat és que l’usuari obté una versió espanyola, tal com volia, en lloc d’una versió en anglès.

Fes-ho o no, com vulguis… podem esperar que algun dia els navegadors tinguin configuracions per defecte més sensibles per tal que això no sigui necessari.

 

Sempre inclou també un enllaç regular

Com que hem mencionat ja diverses vegades, els usuaris malauradament no sempre configuren el seu navegador correctament per a les seves preferències d’idioma. A més de vegades estan utilitzant navegadors pertanyents a d’altres persones (incloent llocs públics com  biblioteques i cibercafès), que pot ser que estiguin configurats amb preferències d’idioma diferents a les de l’usuari. També podria ser que els usuaris estiguin interessats en veure més d’una de les versions d’idioma, perquè potser tenen fluïdesa en més d’un idioma o perquè estan intentant aprendre’n un altre. Així, és important donar a l’usuari l’oportunitat de veure altres versions de les teves pàgines multilingües a part de la que se li mostra per defecte. Ho pots fer mitjançant la inclusió de vincles a cada pàgina amb negociació d’idioma a totes les altres versions d’idioma de la pàgina. Enllaçant directament amb mypage.html.es, sempre arribes a la versió en espanyol sense importar quina configuració ha posat l’usuari.

Recomano, però, que no utilitzeu imatges de banderes per a aquests enllaços, tot i que sigui bastant comú; és un enfocament equivocat, ja que les banderes representen països, no idiomes. L’anglès hauria de ser representat per una bandera britànica o per una bandera americana? Quin idioma hauria de representar la bandera canadenca? (Tant l’anglès com el francès són llengües oficials en aquell país.) I les banderes no són necessàriament úniques! És millor utilitzar el nom de cada idioma, en aquest idioma, com a text per a l’enllaç.

També podeu incloure una etiqueta LINK que faci referència a les versions alternatives de l’idioma, com aquesta:

<link rel=”alternative” lang=”fr” hreflang=”fr” title=”En Français” href=”mypage.html.fr”>

Això fa que els navegadors que suporten aquest element ofereixin algun tipus d’interfície d’usuari que permet l’accés a les diferents versions d’idioma. No obstant això, ja que el servei de suport no és molt bo en els navegadors actuals, aquest no hauria de ser l’únic camí que facis servir per enllaçar a les versions alternatives.

 

Una qüestió interessant: si tenim totes les pàgines del nostre lloc web preparades per a ser servides a través de la negociació d’idioma, si els enllaços de navegació dins del lloc web ens porten a la versió “genèrica” de la URL de cada pàgina (per tant subjectant cada enllaç a la negociació idioma), o a les versions d’idioma específiques que corresponen a la versió d’idioma de la pàgina que s’està veient. Aquesta és una qüestió difícil. Si utilitzem URLs “genèriques”, pot resultar frustrant per a algú que està intentant, per la raó que sigui, navegar pel lloc en un idioma diferent del que està configurat en la seva configuració de navegador, però acaba sempre amb una versió d’idioma diferent i ha de fer clic a l’enllaç a l’idioma adequat en cada pàgina. Hi ha un bon argument per mantenir l’usuari en aquell idioma una vegada que aquest l’ha seleccionat seguint un enllaç específic. D’altra banda, si fem això, estem animant a que altres, així com els indexadors de motors de cerca, a crear enllaços a les URLs específiques d’idioma del nostre web, prescindint de la negociació, ja que les URLs genèriques no apareixeran en els nostres enllaços interns. Això significa que un munt de nous usuaris arribaran al nostre lloc web directament a través d’aquests enllaços, i la negociació mai tindrà l’oportunitat de produir-se. Podria ser que no l’hagis afegit en absolut en aquest cas. Enllaçant les URLs genèriques estem mantenint els enllaços negociats allà fora com a punts d’accés al nostre lloc (tot i que els específics d’idioma també seran enllaçats i indexats, ja que també tenim enllaços directament amb ells).

Finalment vaig aconseguir una solució a aquest dilema; si afegiu aquest JavaScript a la capçalera de les vostres pàgines:

<SCRIPT LANGUAGE=”JavaScript” type=”text/javascript”>

function settaglinks(tag, lang)
{
anchors = document.getElementsByTagName(tag);
for (i=0;anchors[i];i++)
{
if (anchors[i].href.lastIndexOf(‘.html’) == anchors[i].href.length-5 &&
anchors[i].href.indexOf(‘yourdomain.example’) >= 0)
{
anchors[i].href = anchors[i].href+’.’+lang;
}
else if (anchors[i].href.charAt(anchors[i].href.length – 1) == ‘/’ &&
anchors[i].href.indexOf(‘yourdomain.example’) >= 0)
{
anchors[i].href = anchors[i].href+’index.html.’+lang;
}
}
}

function setlinks(lang)
{
if (document.location.href.lastIndexOf(‘.’+lang) == document.location.href.length-3)
{
settaglinks(‘a’, lang);
settaglinks(‘link’, lang);
}
}

</SCRIPT>

i llavors inserteu onload=”setlinks(‘en’)” en la vostra etiqueta <BODY> (canviant ‘en’ al codi d’idioma corresponent a la pàgina donada i “yourdomain.example” al nom del vostre domini), llavors tots els enllaços es canviaran de genèrics a versions específiques d’idioma si l’usuari accedeix a la pàgina amb un URL específic d’idioma, però no si arriben a la pàgina a través d’una URL genèrica que tingui l’idioma negociat. Com a mínim això passarà si l’usuari ha habilitat JavaScript i el seu navegador és compatible amb totes les característiques utilitzades per aquest script. Si no és així, s’hauria de “degradar amb gràcia” deixant a banda els enllaços. L’efecte és que els usuaris que escullin una versió d’idioma explícitament clicant en un enllaç a aquesta veuran a partir d’aleshores enllaços dins d’aquesta idioma, mentre que els usuaris que permetin que el seu navegador triï l’idioma per ells es quedaran amb les adreces URL genèriques; a més, els motors de cerca (que en general ignoren JavaScript) veuran i indexaran les URL genèriques.

Algunes de les coses que estic fent aquí estan molt allunyades de la meva normal filosofia de mantenir les coses simples, però a vegades t’has de complicar el just i necessari per aconseguir fer la feina… res més.

 

Conjunts de caràcters i codificacions

Només estic trient el tema dels conjunts de caràcters i les codificacions per assenyalar que són un altre tema diferent dels idiomes, tot i que sovint es confonen. Ja tinc una altra pàgina sobre qüestions de caràcters i fonts. L’especificació d’un idioma en particular a través d’un atribut HTML o una capçalera HTTP no té cap implicació pel que fa a quina codificació de caràcters estigui utilitzant el document, o quin tipus de lletra ha de ser utilitzat per mostrar-lo, encara que els navegadors possiblement utilitzin diferents tipus de lletra depenent de l’idioma. La confusió prové del fet que llengües diferents requereixen un conjunt de caràcters diferent, de vegades només lleugerament diferents entre ells (el mateix alfabet bàsic però diferents lletres accentuades o altres signes diacrítics i de puntuació) i de vegades radicalment diferent (un alfabet diferent com el grec o el ciríl·lic o un sistema d’escriptura no alfabètic com el xinès o el japonès), i per tant amb codificacions específiques i tipus de lletra associats a un idioma determinat.

És encara inadequat assumir que un document utilitza una codificació de caràcters particular només perquè és la més utilitzada en la seva idioma. Una cita en un document podria ser etiquetada com lang=”ru” perquè està escrita en rus, però no està escrita en alfabet ciríl·lic perquè ha estat transliterada a l’alfabet romà (com “glasnost” i “perestroika”). Fins i tot si s’utilitza l’alfabet ciríl·lic, hi ha una sèrie de codificacions diferents que inclouen aquest repertori. Així, l’ús de l’etiquetatge d’idioma no és un substitut per anunciar correctament la codificació de caràcters del document en la resposta del teu servidor HTTP . Això es pot fer en un arxiu .htaccess:

AddDefaultCharset ISO-8859-1

Aquesta línia es pot utilitzar si tots els seus documents compleixen la codificació ISO-8859-1 (utilitzable per a la majoria de llengües europees occidentals). Si utilitzeu diferents codificacions per a documents en diferents llengües, haureu de ser més avançats, potser utilitzant extensions d’arxiu diferents per a cadascun i ajustant la configuració adequadament. (Quan vaig escriure això per primera vegada ja fa uns quants anys, tanta multiplicitat de codificacions era encara comú, però en l’actualitat és cada vegada més popular fer-ho tot en UTF-8, una codificació que suporta el repertori Unicode sencer. Afortunadament, molts editors de text (incloent-hi el que jo faig servir, UltraEdit), dona suport a l’edició nativa en UTF-8, així que és factible).

Leave a Comment

Your email address will not be published. Required fields are marked *