Application localizable et nombre de langues

Version imprimable

01/02/2009, 22h06
rvzip64

Application localizable et nombre de langues

Salut tout le monde,
Je suis entrain de m 'entrainer à faire une appli localizable, tout va bien , sauf que je n'arrive pas à trouver le moyen de savoir combien de langue sont disponibles.

Pour être plus clair, je voudrais faire une combobox avec le nom des langues disponibles pour que l'utilisateur puisse choisir.

Merci d'avance

Tu as utilisé le système de localisation standard de Windows Forms, avec des assemblies satellites ?

Dans ce cas, il y a 2 méthodes possibles :

Parcourir toutes les cultures existantes (avec CultureInfo.GetCultures(CultureTypes.AllCultures)) et vérifier si une chaine spécifique existe dans les ressources pour cette culture (simple mais un peu lent)

Parcourir les sous-répertoires de ton appli et vérifier la présence de l'assembly satellite :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
        // Enumère les cultures disponibles
        private static ReadOnlyCollection<CultureInfo> GetAvailableCultures()
        {
            List<CultureInfo> list = new List<CultureInfo>();
 
            string startupDir = Environment.CurrentDirectory;
            Assembly asm = AssemblyManager.GetEntryAssembly();
 
            CultureInfo neutralCulture = CultureInfo.InvariantCulture;
            if (asm != null)
            {
                NeutralResourcesLanguageAttribute attr = Attribute.GetCustomAttribute(asm, typeof(NeutralResourcesLanguageAttribute)) as NeutralResourcesLanguageAttribute;
                if (attr != null)
                    neutralCulture = CultureInfo.GetCultureInfo(attr.CultureName);
            }
            list.Add(neutralCulture);
 
            if (asm != null)
            {
                string baseName = asm.GetName().Name;
                foreach (string dir in Directory.GetDirectories(startupDir))
                {
                    // On vérifie que le nom du répertoire correspond à une culture valide
                    DirectoryInfo dirinfo = new DirectoryInfo(dir);
                    CultureInfo tCulture = null;
                    try
                    {
                        tCulture = CultureInfo.GetCultureInfo(dirinfo.Name);
                    }
                    // Ce n'est pas une culture valide : on ignore l'exception et on passe
                    // au répertoire suivant 
                    catch (ArgumentException)
                    {
                        continue;
                    }
 
                    // On vérifie que le répertoire contient des assemblies satellites
                    if (dirinfo.GetFiles(baseName + ".resources.dll").Length > 0)
                    {
                        list.Add(tCulture);
                    }
 
                }
            }
            return list.AsReadOnly();
        }

01/02/2009, 23h10
rvzip64

merci tomlev,

J'utilise en effet les assemblies satellites et je vais prendre ta seconde méthode qui est plus adaptée.

Aller hop je me met a la "convertir" en pascal :D

Merci encore
01/02/2009, 23h23
rvzip64

par contre si cela ne te dérange pas je serais bien preneur d'un ou deux commentaires en plus, voir une petite explication pour que je comprenne bien le code.

Merci d'avance
02/02/2009, 00h41
tomlev
1. On vérifie s'il existe un NeutralResourcesLanguageAttribute défini sur l'assembly. Cet attribut indique la culture "par défaut" utilisée dans l'assembly principal. Si oui, on ajoute la culture correspondante dans la liste.
2. On récupère le nom de l'assembly principal, qui est le nom de base des assemblies satellites
3. On parcourt les sous répertoires. Pour chacun, on vérifie si son nom correspond à une culture (par exemple "fr", "en-US", etc...)
4. Si c'est le cas, on regarde s'il contient un fichier "<nom de l'assembly>.resources.dll"
5. Si oui, on ajoute la culture à la liste
02/02/2009, 09h19
rvzip64

Merci
02/02/2009, 13h20
Greybird

Bonjour,

Le Environment.CurrentDirectory est risqué, car le CurrentDirectory peut bouger durant l'exécution. Je pense que http://faqcsharp.developpez.com/inde...st#syst_appdir est plus approprié

Juste une petite précision au passage : ce code ne fonctionne pas si les assemblies satellites sont installés dans le GAC.
Plus anecdotique, il ne prend pas en compte non plus les types de chemins
[application base] / [culture] / [assembly name] / [assembly name].dll
Je ne suis pas sûr non plus qu'il gère les privatePath.
Cela reste néanmoins tout à fait approprié pour le cas classique de déploiement.

Plus d'info sur la résolution d'assemblies et les chemins recherchés :
http://msdn.microsoft.com/en-us/library/15hyw9x3.aspx

Cordialement,
02/02/2009, 14h26
rvzip64

Greybird,

Tu proposes d'utiliser quelle méthode alors?
02/02/2009, 14h34
Greybird

Si tu maîtrises l'application, tu devrais maîtriser la façon dont sont déployés les assemblies non ?
Assure-toi juste que le code soit en correspondance avec ce déploiement.
Il est en effet relativement raisonnable de penser qu'un utilisateur ne déplacera pas les assemblies pour les réorganiser.

En dehors de ma remarque sur le CurrentDirectory, qu'il ne faut pas utiliser à mon sens, les autres remarques sont destinées à préciser la réponse pour le cas où quelqu'un d'autre viendrait à utiliser ce code et tomberait dans un cas non géré.
02/02/2009, 14h38
rvzip64

Désolé je suis débutant en Dot Net.

Je pensais, vu ton message précédent, que tu avais une meilleure méthode.

Désolé
02/02/2009, 14h44
Greybird

A mon sens, et sans catalogue de langues gérées, il n'y a pas de méthodes rapides et complètes.

Une méthode complète pourrait être de se baser sur les méthodes de chargement d'assemblies (Assembly.Load/Assembly.ReflectionOnlyLoad), mais elle imposerait de parcourir l'ensemble des cultures, ce qui en fait un bon nombre. De plus, les cultures peuvent prendre plusieurs formes (cultures neutres ou spécifiques par exemple), ce qui rajoute encore à la complexité.
02/02/2009, 14h58
rvzip64

Et je pose surement une question bête, mais comment puis-je faire un "catalogue de langues" ?
02/02/2009, 15h43
Greybird

A peu près d'autant de manières que tu le souhaites.

Il peut être en dur dans l'application, ça peut être un fichier à côté de l'application (app.config, fichier plat, xml, autre format,...), une bdd, un répertoire avec un fichier par langue disponible, etc

Le tout étant que quelque part tu aies l'information sur les langues que tu gères. Au lancement de l'application, tu charges ce catalogue, et tu propose à l'utilisateur les langues dans la combo.
02/02/2009, 15h55
rvzip64

ok parfait je me penche sur cette méthode alors
02/02/2009, 16h21
tomlev

Citation:

Envoyé par Greybird

Le Environment.CurrentDirectory est risqué, car le CurrentDirectory peut bouger durant l'exécution. Je pense que http://faqcsharp.developpez.com/inde...st#syst_appdir est plus approprié

Exact...
On peut aussi utiliser Process.GetCurrentProcess().StartInfo.WorkingDirectory, ça évite de faire un truc crado avec un Substring sur la ligne de commande...

Citation:

Envoyé par Greybird

Juste une petite précision au passage : ce code ne fonctionne pas si les assemblies satellites sont installés dans le GAC.
Plus anecdotique, il ne prend pas en compte non plus les types de chemins
[application base] / [culture] / [assembly name] / [assembly name].dll
Je ne suis pas sûr non plus qu'il gère les privatePath.

Exact à nouveau...
La solution la plus générique serait sans doute la première que j'ai suggérée : énumérer les cultures existantes et tester si les ressources sont définies pour cette culture (avec le ResourceManager). Mais je sais pour l'avoir déjà utilisée qu'elle est assez lente (quelques dizaines, voire centaines, de cultures à tester, avec recherche d'assembly satellite à chaque fois...)

Donc au final, le plus simple est sans doute d'utiliser un simple fichier catalogue
02/02/2009, 16h39
Greybird

Citation:

Envoyé par tomlev

Exact...
On peut aussi utiliser Process.GetCurrentProcess().StartInfo.WorkingDirectory, ça évite de faire un truc crado avec un Substring sur la ligne de commande...

Non, les assemblies sont résolus par rapport à l'application base, et par défaut, ce n'est pas le working directory, mais le répertoire de l'assembly contenant la méthode Main.
Pour Windows Forms, le plus simple est :

Code:

Application.StartupPath

qui est indiqué en commentaire dans la FAQ.
02/02/2009, 16h47
rvzip64

GAC, c'est pour le garbage collector ?
02/02/2009, 18h16
tomlev

Citation:

Envoyé par rvzip64

GAC, c'est pour le garbage collector ?

Global Assembly Cache