Lorsqu'on veut faire une interface utilisateur multilingue, les textes dans des langues autres que celle de base (bien souvent l'anglais) risquent de demander plus de place.
Si on utilise un système où les éléments se redimensionnent correctement en fonction de leur contenu, ce ne sera pas vraiment un problème. Par contre, si les éléments sont positionnés de manière absolue (par exemple avec des coordonnées x-y en pixels), alors il faudra prévoir de la place supplémentaire pour les textes traduits.
IBM recommande des réservations de place dans cet article, si on part de textes en anglais.
Je me suis alors demandé: est-ce que je dois prendre ces conseils comme valides pour n'importe quelle langue? Et si les langues que je cible ne comprennent pas l'anglais?
C'est là que rentre en action… le logiciel libre :-) Celui-ci nous fournit une source intarissable de traductions, comme par exemple celles de KDE.
À partir de là, il ne suffisait plus que de faire des statistiques sur ces textes. Que vous pouvez retrouver sur cette page.
Pour effectuer le calcul des longueurs des textes, j'ai utilisé les polices «sans-serif» choisies par Fontconfig sur mon système (Kubuntu). Le script Python (d'une qualité toute relative) et les données sont disponibles.
La langue la plus concise est donc le mandarin, et parmi celles qui demandent le plus de place, le français et l'allemand sont en bonne position.
# i18n ?
Posté par Atem18 (site web personnel) . Évalué à 1.
Bonjour. Est-ce que quelqu'un pourrait m'expliquer l'origine de i18n ? Merci d'avance.
[^] # Re: i18n ?
Posté par Fabimaru (site web personnel) . Évalué à 10.
C'est une abréviation pour «internationalization». Le «i» et le «n» sont la première et la dernière lettre. Le 18 correspond au nombre de lettre entre les deux.
Il y a aussi «l10n» (localization).
[^] # Re: i18n ?
Posté par ✅ ffx . Évalué à 10.
On peut en conclure que la langue la plus concise doit être celle dans laquelle "internationalisation" s'écrit "i18n"
[^] # Re: i18n ?
Posté par Axone . Évalué à 9.
InternationalisatioN, 18 lettres entre le I du début et N de fin.
[^] # Re: i18n ?
Posté par Tom D . Évalué à 10.
Petit truc: Lorsque tu te poses ce genre de question, essaie avec un moteur de recherche (www.google.com, www.bing.com, …).
Par exemple:
https://duckduckgo.com/?q=i18n
Premier résultat: "Origin Of The Abbreviation I18n For Internationalization"
Voila voila, content de pouvoir aider, de rien. OK OK, je sors ->[]
Tom
[^] # Re: i18n ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
ouai mais non. Demander à une machine, c'est humainement moins sympa. Quoi de mieux que d'avoir des commentaires en plus dans linuxfr, ou de se prendre des RTFM dans la tronche ? voilà de quoi avoir du lien humain, du lien sociale ! (Je sors aussi ->[])
# Axiomatique différente = IHM différente
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
L'IHM n'est pas toujours la même en fonction de l'axiomatique choisie. Par exemple, je ne supporte pas le 'click to focus' et reste sur le traditionnel 'follow mouse' des UNIX. L'ancienne IHM de Gimp par exemple est une horreur en 'click to focus' ce qui explique pas mal de soucis sous MS Windows.
Avec les langues, il me semble qu'on ne peux pas tout adapter automatiquement. Il y a des langues verticales, d'autres horizontales de gauche à droite ou de droite à gauche. Bref, de la diversité. Or les écrans ne sont pas carrés donc tous les modes ne sont pas équivalents. Il y a toujours des cas ou une IHM ne pourra pas être adaptées automatiquement sans une partielle adaptation au contexte locale.
C'est pas plus mal au final. La pensée unique n'ayant jamais été une bonne chose ;-)
[^] # Re: Axiomatique différente = IHM différente
Posté par Fabimaru (site web personnel) . Évalué à 7.
En informatique, il n'y a pas vraiment de texte vertical. Les japonais et chinois, qui traditionnellement lisent verticalement de droite à gauche, lisent horizontalement de gauche à droite sur ordinateur. Par contre, si il s'agit de créer des documents imprimés (comme des contrats), je suppose qu'il faut penser à d'écriture verticale.
Sinon il y a plein d'autres problématiques bien chiantes à mettre en œuvre:
* le texte bidirectionnel comme tu l'as mentionné (quand les deux sens sont mélangés ça doit être un bonheur)
* la gestion de la grammaire (par exemple les pluriels)
* les calendriers comme l'Hijri qui demande des calculs de conversions non-triviaux
* les nombres non-arabes
* etc, etc…
[^] # Re: Axiomatique différente = IHM différente
Posté par saltimbanque (site web personnel) . Évalué à 3.
Le chinois a renoncé au vertical mais je n'ai pas super lien sous la main
[^] # Re: Axiomatique différente = IHM différente
Posté par Maclag . Évalué à 6.
Ils ont même renoncé à la direction gauche vers droite. Tu n'as pas besoin de source: plus personne n'utilise l'écriture verticale avec droite vers gauche depuis belle lurette. On ne trouve ça que dans les textes anciens.
La Chine a également adopté un système d'écriture dit "chinois simplifié" avec une certaine standardisation des traits et symboles de base qui composent les caractères.
[^] # Re: Axiomatique différente = IHM différente
Posté par Jiehong (site web personnel) . Évalué à 5.
Pas partout !
À Taïwan, ça n'a pas été simplifié, et la grande majorité des romans est toujours écrite verticalement, et de droite à gauche. Pareil pour les mangas. Dans les journaux, c'est un mélange des deux.
Mais sur l'internet, cela n'a jamais vraiment été possible…
[^] # Re: Axiomatique différente = IHM différente
Posté par pyknite . Évalué à 1.
v P
r a
a s
i
!
[^] # Re: Axiomatique différente = IHM différente
Posté par fearan . Évalué à 2.
mouais, pas concluant, ton i est complètement décalé à cause de l'image de pingouin (ou manchot je sais plus) ça me donne plus un
Pas Vra
i!
Je sais bien qu'a l'époque des claviers qui se blo
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Axiomatique différente = IHM différente
Posté par ckyl . Évalué à 4. Dernière modification le 14 juillet 2013 à 23:36.
Pour le web, si tu travailles proprement et que tu reposes sur des outils qui n'ont pas été conçu par trois pelés dans leur coin ca marche assez facilement. Faut juste faire attention à ce que tu fais, et remonter ce genre de problématique aux designer/UX quand ils partent sur des voies qui vont poser problème. Mais le boulot est déjà bien prémâché.
Pas d'expérience dans le client lourd mais ca doit pas être plus méchant.
Ah le bonheur de travailler sur des trucs où tu dois supporter 50 langues, 10 calendriers, et comme on est sympa on localise aussi les DSL hein ! Histoire de bien foutre la grouille.
[^] # Re: Axiomatique différente = IHM différente
Posté par groumly . Évalué à 3.
Ca depend. Sur un telephone, ou tu bosses tres dur pour designer un truc (en anglais evidemment) ou le principal est "above the fold" et que tu te retrouves avec des lignes qui wrappent tout d'un coup, ca devient problematique. Tu peux jouer sur les tournures de phrases etc. mais c'est loin d'etre evident.
Et apres, tu te retrouves au japon, et ta localisation veut dire ajouter deux colonnes a ta table User pour les noms phonetiques, et un changement d'api REST, et ta recherche "free form text" implique un changement au coeur de l'indexeur pour matcher a la fois le katakana et l'hiragana (desole si j'ecorche les noms, tout ca est encore nouveau pour moi).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Axiomatique différente = IHM différente
Posté par fearan . Évalué à 3.
en fait vu comment les français et allemands écorche mon nom d'origine alsacienne, (ou du moins de la région), ajouter une colonne phonétique pour toutes les langues serait pas mal ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Axiomatique différente = IHM différente
Posté par groumly . Évalué à 6.
Le japonais est fun, avec les noms phonetiques qui requierent 2 champs de plus pour les registration d'utilisateurs…
Sinon, en pratique, ya deux genres de gens:
- ceux qui pensent que l'autolayout va corriger tous les problemes
- ceux qui ont de l'experience et/ou ceux qui font un bon boulot, et qui savent qu'il va falloir repasser derriere, ajuster un certain nombre de choses, revoir une traduction ou deux, parce que vraiment, ca le fait pas c'st trop long/court etc.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Pseudo-localisation
Posté par flan (site web personnel) . Évalué à 10. Dernière modification le 14 juillet 2013 à 23:42.
Un truc pas mal, c'est la pseudo-localisation.
Pour faire simple, au lieu d'écrire « Account Settings », on écrit « !!! Àççôûñţ Šéţţîñĝš !!! ». Ça combine plusieurs avantages :
Il doit être assez facile de générer des fichiers de pseudo-localisation à partir des fichiers .mo classiques.
[^] # Re: Pseudo-localisation
Posté par Professeur Méphisto . Évalué à 10.
ahhh ! c'est donc pour ça que j'ai des mails qui me parlent de \/|ÀGRÂ : ils testent l'i18n des logiciels de publipostage… Je vais leur répondre pour les aider au débogage.
# Le chinois triche
Posté par Renault (site web personnel) . Évalué à -3.
C'est facile pour le chinois d'être concis, cela fonctionne normalement encore en idéogramme avec du coup un caractère = un mot ou presque.
Cependant cela requiert pour parler couramment le chinois de connaitre quelques milliers de signes différents par cœur et un apprentissage beaucoup plus long pour arriver au même niveau de maitrise.
En plus, devant autant de signes différents, chaque caractère est codé sur 4 octets normalement contre 1 pour les langues en alphabet latin. Ce qui peut prendre ainsi plus de place en mémoire au final.
Je ne vois pas du coup comment on peut comparer la concision de langues ayant une approche linguistique si différentes, il faudrait le faire en se limitant à un alphabet commun pour que cela ait un minimum de sens.
[^] # Re: Le chinois triche
Posté par Strash . Évalué à 9.
Je ne vois pas trop où tu veux en venir. Ce n'est pas une compétition, c'est un exercice qui consiste a comparer la place prise par les textes dans les applications, dans différentes langues. Dans ce cas d'étude, le chinois est le plus concis, c'est un fait.
[^] # Re: Le chinois triche
Posté par FDF (site web personnel) . Évalué à 10.
J'utilise professionnellement beaucoup de documents bilingue Anglais Chinois. La concision du Chinois est indéniable, mais doit tout de même être un peu relativisé.
Il est impossible d'utiliser de trop petites police car la densité d'information dans chaque caractère est supérieure. Si on écrit trop petit, cela devient très difficile à lire.
[^] # Re: Le chinois triche
Posté par Zenitram (site web personnel) . Évalué à 5.
Tout est vrai mais… Ici, on parle des développeurs qui doivent afficher.
Et autant la RAM pour du texte ça va bien, autant la largeur des colonnes…
Des gens se limitent volontairement à une zone du monde, pendant que d'autres réfléchissent à comment afficher dans la langue de l’utilisateur partout dans le monde (ou quand la personne se déplace).
Tu n'as pas compris le sens de l'étude : le design d'interface.
[^] # Re: Le chinois triche
Posté par Renault (site web personnel) . Évalué à 1.
Bah mon commentaire n'est pas si trollesque que ça.
Avec des caractères ayant une densité d'information plus élevée, tu ne peux pas te permettre d'écrire trop petit et en plus les caractères chinois ont tendances à prendre plus de volume que ceux de l'alphabet latin…
Bref, c'est à prendre en compte et l'étude ne parle normalement que du nombre brut de caractère.
Je dis juste que de compter le nombre de caractères ne suffit pas à cause de la variance de la taille des caractères mais aussi du volume pris…
Du coup soit tu te limites à un seul alphabet, soit tu prends en compte le volume final et non juste le nombre de caractères. Et là ce serait super pertinent de la mort qui tue.
Comment tu peux supposer à partir de rien que je souhaite qu'on ne traduise pas les textes en langue asiatique ? J'ai fait partie de l'équipe de traduction d'un logiciel, je sais l'importance de ce travail…
Je pense surtout avoir compris plus vite que toi les limites de cette approche dans ce but…
[^] # Re: Le chinois triche
Posté par Fabimaru (site web personnel) . Évalué à 3.
La taille des textes utilisée pour calculer l'expansion requise est exprimée en pixels. Chaque texte a été dessiné avec une police de la même taille, c'est peut-être un point faible: un texte français sera peut-être lisible en police 10, mais peut-être pas un texte chinois. Ceci dit, quand je regarde Wikipedia, j'ai l'impression que la même taille est utilisée dans toutes les langues.
Bon, si le but était vraiment de comparer la concision des langues, j'aurais dû ne pas grouper les statistiques par nombre de caractères du texte source. Le but était de me dire: si mon interface va être traduite de la langue X à la langue Y, alors je dois réserver pour un texte donné une certaine quantité de place. Je veux à la fois que mon interface soit compacte, mais je veux aussi limiter le nombre de cas où je vais devoir retoucher la mise en page manuellement.
[^] # Re: Le chinois triche
Posté par Maclag . Évalué à 5.
Tu t'es trompé de journal. Ton commentaire aurait sa place dans ce journal-ci.
Et comment vas-tu choisir cet alphabet commun sans favoriser à outrance certaines langues qui l'utilisent naturellement face à d'autres langues pour qui il est totalement étranger?
(J'ai peur qu'on me présente l'esperalphabet…)
Au passage, le codage des caractères chinois n'a pas à être sur 4 octets. En UTF-8, on a choisi de mettre d'abord les caractères ASCII, puis on a classé les suivants. Le Chinois prend plus d'octets par conception de la table.
Si on avait "rangé" les caractères chinois les plus utilisés en premier, et l'alphabet latin tout à la fin, on pourrait dire qu'un texte écrit en langue latine prend énormément plus de place en mémoire qu'un texte chinois (moins de signes, et la plupart sur un ou deux octets, contre beaucoup de signes chacun codé sur 3 octets).
Par contre, il est certain que les fontes chinoises prennent plus de place sur le disque.
[^] # Re: Le chinois triche
Posté par Zenitram (site web personnel) . Évalué à 5.
Je te rassure : il l'a déjà fait dans le journal que tu cites.
Mais à l'heure de la télévision UHD, qu'est-ce qu'on peut s'en foutre de la place du texte sur le disque…
(surtout qu'en pratique, vu qu'il y a moins de caractères, ça reste à voir ce "plus de place sur le disque" au final).
[^] # Re: Le chinois triche
Posté par 태 (site web personnel) . Évalué à 1.
Si tu ne stockes que les caractères effectivement utilisés, c'est envisageable. Cependant, dès que tu ajoutes un champ de texte, tu es obligé de stocker les milliers de caractères de la fonte ce qui prendra plus de place qu'une police pour latin9.
D'autre part, quand tu stockes un texte écrit dans un alphabet petit, tu peux faire de la compression efficace. Si tous les caractères de ton texte sont différents (ce qui pourrait arriver avec une interface en chinois), la compression ne sert à rien.
C'est original de remplacer les disques par des télés.
[^] # Re: Le chinois triche
Posté par Maclag . Évalué à 5.
Sans mauvaise foi, je crois que t'as compris le message (avec lequel je suis d'accord):
À une époque où le moindre téléphone doit être capable de lire des vidéos HD1080, il va être difficile de dire que "on n'a pas pu mettre les fontes chinoises parce que ça prend trop de place!".
[^] # Re: Le chinois triche
Posté par Fabimaru (site web personnel) . Évalué à 2.
Changer de système d'écriture peut-être bénéfique, ce n'est pas forcément un abandon de sa culture. Les coréens utilisaient jadis les signes chinois. Un souverain un jour a introduit un nouveau système adapté au coréen. Par contre le japonais utilise les caractères chinois (entre autres) et c'est pas forcément adapté (un caractère peut avoir moulte prononciations).
Et malheureusement, mes données ne permettront pas de passer de l'interlingua à l'espéranto :-)
[^] # Re: Le chinois triche
Posté par Fabimaru (site web personnel) . Évalué à 3.
Je ne sais pas pour le chinois, mais dans le cas du japonais le texte prend moins de place en Utf-16 (2 octets/caractère bien souvent) qu'en Utf-8 (souvent 3). Par contre si il s'agit de le mettre dans une page web, comme il y aura beaucoup d'ascii, l'utf-8 est intéressant.
[^] # Re: Le chinois triche
Posté par binbin . Évalué à 0.
Genre l'alphabet phonétique international ?
# Très intéressant
Posté par Philippe F (site web personnel) . Évalué à 3.
On savait tous que traduire une interface en français pose un problème de place, mais là on a des stats concrètes.
Je note que en gros, il faut doubler la place pour faire tenir la majorité des textes anglais en français dans une interface graphique. Oups…
# [HS] Débit d'information et langue
Posté par 태 (site web personnel) . Évalué à 7.
Je me rappelle avoir lu (mais ne sais plus où) que si à l'écrit certaines langues comme l'espagnol par exemple sont très verbeuses (c'est confirmé par ibm et kde), à l'oral cependant, la quantité d'information transmise par minute est similaire dans tous les langages. En gros, l'espagnol mettrait en moyenne le même temps à prononcer les 200 mots d'une traduction d'un texte anglais de 100 mots que l'anglais met à prononcer ces 100 mots.
D'une certaine façon, cela pourrait indiquer une borne à la capacité d'analyse du cerveau humain à laquelle les locuteurs se seraient adaptés.
Quelqu'un a déjà entendu parler de ce genre de choses, aurait une référence ? Est-ce que j'aurais inventé ça ?
[^] # Re: [HS] Débit d'information et langue
Posté par Marotte ⛧ . Évalué à 5.
J'ai pas de référence mais pour avoir parlé avec des espagnols je peux confirmer : ils parlent à une vitesse phénoménale (en syllabes par minute) !
[^] # Re: [HS] Débit d'information et langue
Posté par Spyhawk . Évalué à 6.
C'est exact. On en a parlé l'année passée dans les média suite à une étude du Laboratoire Dynamique Du Langage de Lyon.
[^] # Re: [HS] Débit d'information et langue
Posté par FDF (site web personnel) . Évalué à 9.
Il y avait un article de pour la science d'il y a plus d'un an sur le sujet.
L'article pointait quelque chose d'un peu plus fin.
À l'oral (et uniquement à l'oral, car l'étude ne portait que là-dessus), la quantité d'information transmise dépend de la densité d'information et de la vitesse de transmission (c'est vrai de toute transmission et pas que pour une langue, mais ne nous égarons pas). Ainsi, certaines langues sont denses. C'est-à-dire qu'avec peu de sons, elles transportent beaucoup d'information. Mais l'étude montrait que pour ces langues, la vitesse de la parole était faible. À l'opposé, certaines langues moins denses sont généralement parlées avec plus de débit. Mais, au final, la quantité d'information transmise en une minute est à peu près équivalente d'une langue à l'autre.
Si je me souviens bien, la question qui restait ouverte était la cause de ce phénomène. Est-ce que les langues denses empêchaient une diction rapide, car trop difficile à prononcer, ou est-ce qu'en fait la quantité d'information à traiter était fixe, car elle correspond à la capacité du cerveau humain ?
# Nique l'i18n
Posté par calandoa . Évalué à -2.
Je rêve d'un jour où le premier choix pour installer une distro ou un soft sera le mode international, avec textes en anglais, clavier qwerty en mode international, unités international, et où tout fichier ressemblant de près ou de loin à une quelconque tentative de remplacer l'interface avec un dialecte local sera irrémédiablement expulsé. Il y en a marre d'accueillir la terre entière dans son
/usr/share…En ne considérant bien sûr que l'interface, pas le traitement de contenus tel que les dictionnaires orthographiques.
[^] # Re: Nique l'i18n
Posté par Spyhawk . Évalué à 3. Dernière modification le 15 juillet 2013 à 13:18.
Rien ne t'empêche de configurer ta machine personnelle :)
Ca me fait penser à la locale en_xx complètement artificielle, mais oh combien logique et exceptionnelle.
En particulier, j'aime bien le format de date yyyy-mm-dd (à mettre en relation avec la façon dont on exprime l'heure), qui est en pratique utilisée surtout dans certains pays de l'Asie de l'Est.
A part ça, les touches mortes du clavier US international me gavent et je préfère nettement utiliser le clavier US standard et switcher vers un clavier plus approprié pour taper du français. Fun fact: Je voyage pas mal et mon horloge est toujours en UTC :)
[^] # Re: Nique l'i18n
Posté par mornik . Évalué à 3.
La mienne est biologique :°
Et hop je retourne prendre le soleil…
[^] # Re: Nique l'i18n
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 15 juillet 2013 à 17:22.
Surtout je pète un câble dans les discussions entre américain et anglais, je sais jamais (je ne connais pas toujours leur nationalité en plus), alors à défaut : je met yyyy-mm-dd qui met tout le monde d'accord :)
[^] # Re: Nique l'i18n
Posté par Spyhawk . Évalué à 2.
C'est effectivement le principal avantage de ce format :)
[^] # Re: Nique l'i18n
Posté par Fabimaru (site web personnel) . Évalué à 2.
T'as aussi une solution pour le décompte des étages? (celui au dessus du rez-de-chaussée est-il le premier ou le deuxième étage?)
[^] # Re: Nique l'i18n
Posté par Zenitram (site web personnel) . Évalué à 2.
C'est un truc que j'utilise beaucoup beaucoup moins souvent dans mes discussions :).
Donc pas cherché de solution (tout en étant incertain qu'il y en une)
[^] # Re: Nique l'i18n
Posté par Sufflope (site web personnel) . Évalué à 5.
Elle est pourtant évidente. Le RDC est l'étage immeuble[0] donc l'étage au dessus est le premier étage.
Toute autre représentation est une saloperie d'hérésie.
# Homard Serif
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 0.
T'es sûr que c'est pas plutôt des polices « monospaces » que tu voulais choisir ? Car l'empattement influee bien moins sur la longueur du texte que l'espace entre les caractères…
[^] # Re: Homard Serif
Posté par Fabimaru (site web personnel) . Évalué à 3.
Euh, une police «monospace» (à chasse fixe) n'aurait pas du tout convenu. Si tous les caractères ont la même longueur, autant compter directement ceux-ci plutôt que la longueur de leur rendu (en pixels).
J'ai choisi «sans-serif» parce que c'est la police (ou famille de polices) utilisée par Wikipedia pour toutes les langues (enfin, sur mon système). Sous Linux (en tous cas sous Ubuntu), Firefox délègue la sélection de la police à Fontconfig en fonction de la langue de la page (et ça je ne le savais pas). Internet Explorer lui définit la police par famille et par langue au sein de la configuration du navigateur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.