mozilla
Vos résultats de recherche

    Écriture de code localisable

    Cette page présente les bonnes pratiques et des recommandations à suivre en ce qui concerne la localisation lorsqu'on touche à l'interface utilisateur. Elle est destinée aux développeurs de Mozilla et d'extensions.

    Pour des détails techniques, veuillez également consulter la section Localisation du tutoriel XUL.

    À propos des localisateurs

    Quelques notes au sujet des localisateurs pour les développeurs qui traitent rarement avec eux :

    • les localisateurs aiment les outils et n'aiment pas les éditeurs,
    • les outils de localisation sont souvent basés sur des paires clé-valeur,
    • un certain nombre d'entre eux concentrent leurs talents sur la traduction et la langue, et ne sont pas doués pour programmer ou empaqueter des applications.

    Recommandations

    Par conséquent, voici quelques recommandations à suivre pour rendre la localisation de votre code plus aisée :

    Choisissez de bons noms de clés 
    les noms choisis pour vos clés (que ce soit pour un fichier .DTD ou .properties) doivent être descriptifs. Si vous changez la sémantique d'une clé localisée, renommez la clé. Ce sera sans doute un meilleur nom pour la clé, et cela aidera les divers outils à repérer que le changement que vous avez fait n'est pas juste une coquille.
    N'utilisez pas de macros de pré-traitement 
    l'utilisation de #if #else #endif ou #expand est fortement déconseillée. Il y a quelques exceptions à cette règle, mais en général, le fichier localisé doit se conformer aux standards et ne doit pas nécessiter d'outils d'empaquetage pour être transformé. Si vous voulez ajouter un traitement pour compiler des fichiers localisés, assurez-vous d'obtenir l'avis de l10n@. Dans la plupart des cas, vous pouvez aussi juste ajouter le traitement dans le code contenu et référencer les différentes paires clé-valeur dans l10n.
    Faites attention de ne pas faire de suppositions basées sur la grammaire dans vos chaînes 
    couper des phrases en plusieurs clés suppose souvent par inadvertance une grammaire particulière, une structure de phrase, et de telles chaînes composites sont souvent très difficiles à traduire. Lorsque c'est vraiment nécessaire, essayez de laisser de la place aux traducteurs. Un exemple d'une chaîne composite bien utilisée est l'option de Firefox pour les pages visités : le traducteur peut implicitement positionner le champ de texte comme il lui convient.
    Utilisez une bonne structure du répertoire des sources 
    assurez-vous de placer les fichiers localisés au bon endroit. L'ajout de nouveaux répertoires racines est un compromis entre la propriété du module dans le référentiel cvsroot et la facilité de localisation.
    Utilisez une bonne structure du répertoire chrome
    pour un module mod particulier, un chemin tel que jar:ab-CD.jar!/locale/ab-CD/mod/foo.dtd a été largement testé et constitue un bon emplacement pour vos fichiers référencés ainsi : chrome://mod/locale/foo.dtd. Utiliser une telle structure de répertoire facilite la localisation sans le code source et c'est particulièrement recommandé pour les auteurs d'extensions. Les Manifestes JAR peuvent faciliter ceci.

    Impact l10n

    Sur les arbres gelés, la règle est de ne pas appliquer de changements impliquant la localisation. Qu'est-ce à dire ? Un impact sur la localisation est :

    • tout changement sur mozilla/@mod@/locales ; que les localisateurs découvrent quand ils surveillent les changement sur le référentiel à l'aide de requêtes sur Bonsai, comme tout un chacun. Aucun changement signifie que le résultat des requêtes doit être vide.
    • toute chaîne localisée modifiée ou ayant un nouvel usage; Tout ce qui provoque un cycle d'assurance qualité sur nos quelques 80 localisations a un impact sur la localisation.

    Étiquettes et contributeurs liés au document

    Étiquettes : 
    Contributors to this page: Delapouite, BenoitL, Goofy, fscholz, Mgjbot
    Dernière mise à jour par : Delapouite,