Par exemple, j'ai un fichier local anglais par défaut "EN.YML" avec le contenu:
config.i18n.load_path += Dir[File.join(RAILS_ROOT, 'config', 'custom_locales', APP_CONFIG['customer_name']+'.{rb|yml}')]
4 Réponses :
Il ne faut pas écraser votre localisation "EN". Les traductions sont fusionnées. Comme vous pouvez le constater, seules les clés que vous entrez dans Le dernier fichier YML de traduction sera écrasé. store_translations dans les appels de back arrière simples i18n fusion_translations , qui ressemble à ceci:
Je voulais quelque chose de similaire quand nous écrivions une traduction pirate.yml, mais je voulais tout ce qui n'est pas défini dans Pirate.yml à défaut de ce que nous avions dans EN.YML.
Ce que j'ai écrit peut être trouvé sur Github .
GitHub Link n'est plus valide!
Pas valide? Bien que ce soit un très ancien projet, le lien fonctionne toujours pour moi. Obtenez-vous un 404?
Exactement une page non trouvée est ce que je reçois!
@Yanfoto bizarre, le lien fonctionne toujours pour moi (même lorsque déconnecté). Pourrait-il s'agir d'une question HTTPS? Avez-vous besoin du code? Je pourrais gister cela pour vous. Je ne suis pas sûr comment je peux aider sinon ...
Le lien fonctionne lorsque je le copie / la colle et non lorsque vous cliquez dessus! Mystérieux ... mais j'ai déjà trouvé une solution de contournement pour mon problème. Merci!
Je pense que vous pouvez mélanger deux choses différentes.
Le fichier i18n est pour les traductions.
Si vous avez un client qui nécessite un nom spécifique pour certains champs, ce n'est pas une traduction Problème, mais fonctionnalité.
En d'autres termes, je pense que vous avez besoin de quelque chose comme ceci: puis ajoutez la fonctionnalité spécifique ailleurs, par exemple Dans votre vue: Vous pouvez également ajouter un attribut de chaîne à vos clients, défaut des "messages". Ensuite, votre vue ressemblerait à ceci:
Eh bien, s'il a besoin de 200 modifications de libellé, je dois écrire 200 IFS et ajouter 200 paramètres client, et identiques pour les autres clients utilisant le produit à sa manière. Cela augmenterait fortement la quantité de code. et, si le client spécifique quitte, tous ces IFS resteraient dans le code, alors que sinon, je supprimez simplement le remplacement de la traduction.
Le code n'était qu'un exemple - ce que je voulais dire, c'est que vous ne devriez pas utiliser I18N pour cela. J'ai édité mon commentaire avec d'autres solutions. Si vous continuez à penser à utiliser I18N, pensez à ce qui va se passer lorsque vous devez traduire votre candidature en français, par exemple.
J'ai déjà le français et l'anglais i18n, et sur eux, je charge des substitutions du client. J'ai des locaux / en.yml, des locaux / fr.yml et sur eux, je charge des local / client.en.yml et locals / client.fr.yml, si nécessaire. Je suis désolé, mais je pense vraiment que cette façon est bien meilleure pour les personnalisations simples de formulation
Je ne suis pas sûr quand cela a été ajouté aux rails, mais en 4.2.2, vous pouvez faire: P>
# application.rb
# If key is not found in a locale, we look in fallback
config.i18n.fallbacks = {
"locale_1" => "en",
"locale_2" => "en",
"locale_3" => "de",
}