Traduire un fichier YAML en turc

Variables et suffixes : le vrai piège du turc dans un YAML

Le turc colle ses marques grammaticales au mot : le cas, la possession et le pluriel s’ajoutent en suffixes qui suivent l’harmonie vocalique. Tant que la variable est isolée, rien ne bouge : welcome: "Welcome, %{name}" devient "Hoş geldiniz, %{name}". La difficulté apparaît quand la phrase demande un suffixe sur la valeur de la variable elle-même.

Prenez sent_to: "Sent to %{name}". En turc, « à Ahmet » se dit Ahmet'e, « à Ayşe » se dit Ayşe'ye : le suffixe dépend du nom, inconnu au moment de traduire. Écrire "%{name}'e gönderildi" produira une faute pour une partie des noms. Une bonne traduction contourne la difficulté : "%{name} adlı kişiye gönderildi" ou "Alıcı: %{name}".

Deux conséquences pratiques :

• la variable change souvent de place, car le verbe turc se met en fin de phrase ; c’est normal, seule sa présence compte ;
• les chaînes assemblées par le code, du type "%{count} %{item}", se prêtent mal au turc : des phrases complètes dans le fichier source donnent un résultat plus juste.

İ et ı, mots longs et registre

L’alphabet turc distingue deux i : i/İ avec point et ı/I sans point. La traduction les écrit correctement dans le fichier ; le risque vient après, si votre code change la casse avec une locale qui n’est pas turque. « bilgi » devient alors « BILGI » au lieu de « BİLGİ », et « KAYIT » repassé en minuscules donne « kayit » au lieu de « kayıt ». Si vos boutons ou titres sont mis en majuscules par le code ou par une feuille de style, vérifiez que la langue tr y est bien déclarée.

Les suffixes allongent les mots : ayarlarınızı (« vos réglages », complément d’objet) ou güncellenemedi (« n’a pas pu être mis à jour ») forment un seul bloc, sans espace où couper la ligne. Un libellé court dans la source peut ne plus tenir dans un bouton de largeur fixe.

Côté registre, une interface turque vouvoie en général l’utilisateur (siz), tandis que les boutons emploient l’impératif court : Kaydet, Sil, İptal. Vérifiez sur l’extrait gratuit que ce ton convient à votre produit.

Pluriels, pourcentages et dates en turc

Le turc n’a que deux catégories de pluriel CLDR, one et other, et après un nombre le nom reste au singulier : « 1 dosya », « 5 dosya », jamais « 5 dosyalar ». Manuce adapte les blocs de pluriel à ces deux catégories ; il est donc normal d’obtenir one: "%{count} dosya" et other: "%{count} dosya" avec le même texte. Ce n’est pas un oubli.

Le signe pour cent se place avant le nombre : « 50% off » devient « %50 indirim ». Or, en YAML, une valeur qui commence par % doit être entre guillemets, et Manuce conserve les guillemets de la source. Si la valeur d’origine n’en avait pas, contrôlez cette ligne au chargement.

Les formats de date ne sont pas traduits : "%m/%d/%Y" reste tel quel. L’usage turc est %d.%m.%Y (31.12.2025) : modifiez vous-même ces clés. Même vigilance pour les séparateurs si votre fichier en définit : le turc écrit 1.250,50, avec virgule décimale et point des milliers.

Ce que Manuce vous rend, et ce qui reste de votre côté

Vous récupérez le même fichier, dans le même format, prêt à remettre dans le projet : indentation, ordre des clés, guillemets, commentaires, fins de ligne, encodage et BOM conservés ; seules les valeurs changent. Pour Rails, Symfony, Hugo et i18n-js, la clé racine de langue est gérée (en: devient tr:), et les ancres ainsi que les blocs | et > sont conservés.

Chaque valeur traduite est comparée à la source. Si une variable %{name} ou {name}, ou une balise, manque ou diffère et que l’écart persiste, la valeur source est gardée et le rapport le signale. Ce rapport liste les chaînes traduites, celles laissées telles quelles et la raison.

Ne sont pas traduits : les clés, les valeurs vides, les URL, les adresses email, les nombres, les couleurs, les formats de date, les identifiants et tout ce qui est marqué non traduisible. Le prix porte sur les mots des valeurs, clés et balises exclues.

Restent à votre charge : placer le fichier turc au bon endroit, adapter les formats de date, revoir les chaînes assemblées par le code et régler la casse turque dans votre application.

Préparer le fichier et vérifier le résultat

• Encodage : enregistrez la source en UTF-8. L’encodage étant conservé, un fichier en Latin-1 (ISO-8859-1) ne peut pas contenir ğ, ş, ı ni İ.
• Termes à garder : nom de produit, marque, nom de module. Ce qui est marqué non traduisible est laissé tel quel ; pour le reste, vérifiez l’extrait gratuit puis la traduction.
• Apostrophes : le turc en place une entre un nom propre et son suffixe (Manuce'a, İstanbul'da). Dans une valeur entre guillemets simples, YAML impose de la doubler : 'Manuce''a hoş geldiniz'. Chargez le fichier rendu avec le parseur de votre framework pour vous en assurer.
• Emplacement : par exemple config/locales/tr.yml pour Rails, translations/messages.tr.yaml pour Symfony, i18n/tr.yaml pour Hugo.
• Test en contexte : affichez quelques écrans en turc pour repérer les libellés trop longs et les i mal mis en majuscules.

En pratique

1. Enregistrez votre fichier YAML en UTF-8 et repérez les valeurs à laisser telles quelles.
2. Déposez-le sur Manuce : devis immédiat sur les mots des valeurs, extrait gratuit en turc.
3. Vérifiez l’extrait (vouvoiement, variables, suffixes) puis lancez la traduction.
4. Récupérez le fichier turc et le rapport, placez-le dans le projet et chargez-le avec votre parseur.
5. Testez quelques écrans : longueur des libellés, majuscules İ/I, formats de date.