Espaces fines insécables entre les guillemets

Personnellement, je m’en moque que l’espace soit fine ou non.

Par contre je ne trouve pas normal que le changement soit fait de manière massive alors qu’il n’y a pas consensus.

Et ça me fatigue de devoir relire des tas de modifications juste pour une espace qui perd un quart de pixel de large. Faire le changement au passage, quand il y a un autre changement à faire, d’accord. Mais ne faire que ce changement là, c’est faire perdre du temps en relecture à tous les traducteurs de Translatewiki.net

Pols12 (talk)00:47, 10 October 2019

Faire perdre du temps ? Tu sembles oublier qu'on a beaucoup de retard sur les relectures. Le plus gros du temps c'est moi qui le passe à faire remonter les statistiques car on a des tonnes de fautes oubliées. Maintenant cela se fait sur l'interface de relecture elle-même. S'il y a des problèmes d'interprétation c'est que la doc est incomplète sur certains messages. De plus ces messages sont eux-mêmes parfois changés dans la version anglaise et on les voit de façon isolée hors contexte qui n'est pas précisé. Fatalement si on modifie de façon synchrone cela va réapparaître à l'interface des rares qui suivent, ce n'est pas pour "tous" les traducteurs. J'ai vu des arguments assez suspects comme le fait que NNBSP ne serait pas pris en charge sur MacOS et iOS, alors que c'est dans les docs même de MacOS et iOS depuis des années. Apple a commis un bogue sur certaines versions anciennes de MacOS lors d'une mise à jour malheureuse quand il a modifié simultanément la prise en charge intrinsèque des espaces dans son moteur et supprimé les mappings de ses polices : c'était cohérent pour les nouvelles versions de MacOS (et n'a pas fait disparaître ces espaces), mais le problème est arivé sur les anciennes versions de MacOS et iOS quand le moteur n'a pas été modifié mais de nouvelles versions des polices sans les mappings ont été chargées : ces polices n'auraient pas du avoir ces mappings supprimés. Cela a été corrigé et ne concerne que les polices Apple boguées qui ont été corrigées à nouveau pour restaurer ces mappings afiun de restaurer la compatibilité. Et cela n'a jamais concerné les autres polices non système. C'est bien une anomalie temporaire avec les anciennes versions (qui étaient correctes à l'origine) mais il n'y a pas eru de changemetn de recommandations (car les NNBSP sont restées nécessaires notamment pour les fines insécables des séparateurs de groupes de chiffres dans les nombres qui avaient disparu; Apple l'a corrigé mais certains rares utilisateurs ont remis des versions incorrectes de ces polices Apple, en fait une seule police était concernée par l'anomalie).On ne peut pas se baser sur ces anomalies transitoires de certains OS et les manipulations hasardeuses des utilisateurs sur leur appareil. Les fines sont standards en faire partout des espaces normales est incorrect et non conforme pour tous les autres utilisateurs qui sont l'immense majorité, y compris les utilisateurs de MacOS et iOS d'appareils assez récents (concernant iOS, les appareils sont nécessazirement anciens et leur batterie à bout de course, il reste les vieilles versions de MacOS où il n'y a pas de raison de ne pas installer les polices corrigées (pas de problème de place). Alors c'est un problème pour 0,000001% des utilisateurs, la très grande majorité voit ce qui est attendu et décrit dans les standards, décrits dans les docs d'Apple, documentés dans les forums Apple, et cohérent avec ce qui est présent dans les bibliothèques communes (CLDR par exemple) utilisées dans des tas de logiciels (y compris d'Apple). Enfin quant à dire que "j'ignore" les commentaires, ce n'est pas vrai mais les commentaire ne sont pas là où il faut quand on doit travailler sur des centaines de message dans l'interface de traduction car on ne les voit pas du tout (on ne voit que les commentaires de dans la page de doc "/qqq". Cela peut aboutir à quelques lignes avec désaccord mais ce n'est rien à côté des centaines de lignes sur lesquelles il y a des corrections tout à fait appropriées. Les désaccords viennent de l'absence de contexte (et de défaut de documentation).

Verdy p (talk)13:59, 2 December 2019

Non, tout est à jour et c’est la police par défaut qui est utilisée (qui ne peut pas être changée sur iOS de toute façon).

Safari est le deuxième navigateur en termes de parts de marché, ça ne concerne donc pas que « 0,000001% des utilisateurs ».

Merci de cesser les arguments fallacieux.

Thibaut (talk)14:26, 2 December 2019

Il suffit pourtant de regarder les nombreux forums de support pour Apple, c'est un bogue connu et admis par Apple et décrit aussi comme tel dans les discussions du standard Unicode. Tout marchait bien avant MacOS 8, corrigé ensuite avec des notes d'Apple. Et sinon le bogue concerne certaines versions d'iOS anciennes aussi. C'est Apple qui s'est planté et ne formate plus les nombres correctement à cause de ça. NNBSP est là depuis longtemps et s'il est invisible sur certains appareils c'est une minorité pas à jour avec les correctifs mais ça ne rend rien d'illisible et il est même préférable de ne rien voir que de voir une espace trop grande. Quant au fait de ne pas pouvoir changer de police c'est faux dans un navigateur même sur mobile.

Sinon encore une fois tu choisis le ton agressif avec un terme comme "fallacieux", plein de mauvaises intentions.

Verdy p (talk)15:44, 2 December 2019

> NBSP (U+00A0) n'est plus recommandé QUE comme repli au cas ou NNBSP (U+202F) ne peut pas être utilisé pour des raisons techniques

> c'est un bogue connu et admis par Apple

On est donc bien dans le cas des limitations techniques (que ce soit une limite inhérente à une architecture, un navigateur ou une mauvaise configuration par défaut ne change pas grand chose). Et les super-logiciels dont tu parles remplaceront automatiquement ces espaces par des espaces fines^^.

Trial (talk)20:58, 8 December 2019