[.NET] Language resources

[Verwijderd]

Het gaat om ASP.NET (C#)

In de global.asax (Application_BeginRequest) is het volgende opgenomen:

code:

Thread.CurrentThread.CurrentCulture = new CultureInfo("nl-NL");
Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture;

Om de uiculture te gebruiken voor de resourcemanager.

Als volgt wordt de resource opgevraagd:

code:

Assembly a = Assembly.Load("<assemblyname>");
ResourceManager res = new ResourceManager("resourcename", a);

of

code:

ResourceManager res = new ResourceManager("resourcename", Assembly.GetExecutingAssembly());

Beide situaties werken bij mij lokaal perfect.

Ik probeer het geheel te runnen op de server en dan gebruikt deze de standaard resource en niet de resource.nl-NL.
Voor dat ik de gegevens ophaal met getstring() geef ik de CultureInfo.CurrentUICulture weer en deze staat dus echt op nl-NL.
Wat kan dit zijn?

Er wordt gewerkt met Visual Sourcesafe. Op de server geef ik een get latest version, daarna een rebuild all en dan starten.

[ Voor 5% gewijzigd door Verwijderd op 13-02-2004 10:22 ]

[whoami]

Hmmm, ik geloof dat ik dat probleem ook al eens gehad heb.

Echt een goede oplossing heb ik er voorlopig ook nog niet voor gevonden (ben de laatste tijd bezig met WinForms), maar als je in je page_load van iedere pagina de juiste Culture zet, dan zou het normaal wel moeten werken.
Bij jou werkt het lokaal ws goed, omdat je regional settings al op nl-NL staan.

[Verwijderd]

whoami schreef op 13 februari 2004 @ 10:25:
Hmmm, ik geloof dat ik dat probleem ook al eens gehad heb.

Echt een goede oplossing heb ik er voorlopig ook nog niet voor gevonden (ben de laatste tijd bezig met WinForms), maar als je in je page_load van iedere pagina de juiste Culture zet, dan zou het normaal wel moeten werken.
Bij jou werkt het lokaal ws goed, omdat je regional settings al op nl-NL staan.

Als ik het volgende in de page_load zet heeft het tot resultaat dat er niets veranderd. Hij blijft altijd de standaard paken.

Thread.CurrentThread.CurrentUICulture = new CultureInfo("nl-NL");

Maar als ik de uiculture opvraag dan staat deze ook goed. Wat kan je dan nog doen?

Zelfs als ik de taalinstellingen hetzelfde zet op 2 verschillende pc's gaat het opde ene goed en op de andere fout.

[ Voor 17% gewijzigd door Verwijderd op 13-02-2004 10:56 ]

[whoami]

Verwijderd schreef op 13 februari 2004 @ 10:43:
[...]
Zelfs als ik de taalinstellingen hetzelfde zet op 2 verschillende pc's gaat het opde ene goed en op de andere fout.

Je applicatie wordt op een server uitgevoerd, het is immers een asp.net applicatie. Het zijn dus de taalinstellingen van de server die zullen genomen worden als de CurrentUICulture niet gezet wordt, of gezet wordt op een culture waarvoor er geen resource-file gemaakt is.
Ben je wel zeker dat je de goeie 'name' hebt meegegeven aan de constructor van de resource-manager?
Ik heb hier momenteel geen ASP.NET source code denk ik, maar ik wil vanavond wel eens kijken.

[whoami]

Ik heb toch net even een vlug testje gedaan, en dat blijkt toch te werken.

Mijn constructor voor m'n ResourceManager ziet er zo uit:

code:

rm = new ResourceManager ("WebTest.strings", Assembly.GetExecutingAssembly);

Waarbij WebTest de naam is van mijn namespace, en strings de naam is van mijn resourcefiles.
(mijn resource - files zijn : strings.en.resx, strings.nl.resx, ....)

[Verwijderd]

whoami schreef op 13 februari 2004 @ 11:14:
[...]


Je applicatie wordt op een server uitgevoerd, het is immers een asp.net applicatie. Het zijn dus de taalinstellingen van de server die zullen genomen worden als de CurrentUICulture niet gezet wordt, of gezet wordt op een culture waarvoor er geen resource-file gemaakt is.
Ben je wel zeker dat je de goeie 'name' hebt meegegeven aan de constructor van de resource-manager?
Ik heb hier momenteel geen ASP.NET source code denk ik, maar ik wil vanavond wel eens kijken.

Mijn structuur is als volgt:

projectname
--ascx
--components
----BLL
----Languages
andere projectname
andere projectname

De projecten zijn gekoppeld.

Dus aan de constructor geef ik het volgende mee:

<namespace>.components.Languages.<naam resource>

code:

ResourceManager res = new ResourceManager("<namespace>.Components.Languages.<resourcename>", Assembly.GetExecutingAssembly());

Het bovenstaande wordt uitgevoerd in een ascx-bestand welke staat in de map projectname --> ascx

[whoami]

Dat krijg ik als volgt aan de praat:

Bv:

code:

Assembly a = Assembly.GetAssembly (typeof(BLL.Class1));
rm = new ResourceManager ("BLL.strings", a);
            
System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo ("en-GB");

Waarbij BLL het project is waarin de resource-files staan, Class1 een class is uit project BBL, en strings het eerste gedeelte is van de naam van de resource-files.

Hmm, volgens de documentatie moet dat met die Application_BeginRequest toch ook wel goed werken. 'k Ga er van 't weekend nog eens moeten naar kijken.

[ Voor 16% gewijzigd door whoami op 13-02-2004 11:55 ]

[tijn]

Je kunt ook eens proberen om in de web.config de culture te zetten:

code:

<!--  GLOBALIZATION
        This section sets the globalization settings of the application. 
-->
<globalization 
    requestEncoding="utf-8"  
    responseEncoding="utf-8" 
    culture="nl-NL" 
    uiCulture="nl-NL"
/>

Ik garandeer niet dat het werkt. Hier wel .

[whoami]

Daarmee ga je de te gebruiken resource hard vastleggen in je code, en dat wil je niet. Stel nu dat ik een engelse versie van die pagina wil zien, en een andere bezoeker een nederlandstalige...

[Verwijderd]

whoami schreef op 13 februari 2004 @ 12:12:
Daarmee ga je de te gebruiken resource hard vastleggen in je code, en dat wil je niet. Stel nu dat ik een engelse versie van die pagina wil zien, en een andere bezoeker een nederlandstalige...

Klopt. Het moet wel variabel blijven.
Tot nu toe nog geen vooruitgang...

[whoami]

Maar je krijgt geen foutmelding? Je krijgt gewoon een 'foute' vertaling?

Heb je dan wel een resource-file die voldoet aan je geselecteerde culture, en ben je zeker dat de 'fall through' resource dan niet gebruikt wordt?

Ik moet wel zeggen dat ik m'n test ook gewoon lokaal gedaan heb, maar normaal zou dat geen verschil mogen maken.

[Verwijderd]

whoami schreef op 13 februari 2004 @ 12:25:
Maar je krijgt geen foutmelding? Je krijgt gewoon een 'foute' vertaling?

Heb je dan wel een resource-file die voldoet aan je geselecteerde culture, en ben je zeker dat de 'fall through' resource dan niet gebruikt wordt?

Ik moet wel zeggen dat ik m'n test ook gewoon lokaal gedaan heb, maar normaal zou dat geen verschil mogen maken.

Als ik het lokaal aanroep gaat het perfect ook met een andere uiculture.
Dus lokaal werkt het met elke taal die ik heb aangemaakt.
Wanner de taal er niet is wordt de 'fall through' resource weergegeven.
Maar dan doe ik het op de server en dan wordt dus de 'fall through' resource gebruikt.
Dat wel.
Maar dus niet de juiste taal. Terwijl deze wel is opgegeven.

Ik ben echt out of option...

Als ik lokaal de resource aanspreek, dan mag ik toch aannemen dat dit hetzelfde is als op de server? Dus zoals weergegeven in mijn startpost.

Conclusie:
Hij pakt altijd de resource.resx en dus niet resource.nl-NL.resx of hoe de uiculture ook is gezet.

[ Voor 30% gewijzigd door Verwijderd op 13-02-2004 13:25 ]

[whoami]

Ben je dan wel zeker dat je de satellite assemblies (de gecompileerde resource-files dus, die een DLL zijn) ook naar die server gedeployed hebt ?
Kijk eens in de bin directory van je webapp, en kijk eens of je daarin voor iedere resource - file een subdirectory terugvind.

[Verwijderd]

whoami schreef op 13 februari 2004 @ 15:22:
Ben je dan wel zeker dat je de satellite assemblies (de gecompileerde resource-files dus, die een DLL zijn) ook naar die server gedeployed hebt ?
Kijk eens in de bin directory van je webapp, en kijk eens of je daarin voor iedere resource - file een subdirectory terugvind.

Ze staan er toch echt............zeer vreemd dat ie ze niet pakt.

Ik heb in een test project hetzelfde gedaan met de language maar dan in 1 project. Dan werkt het perfect. Ook op andere servers.

[whoami]

Ik blijf het toch vreemd vinden hoor.

Ik heb het net even getest zoals in jouw situatie:
- een solution met een ASP.NET webapp project en een ClassLib project. Het ClassLib project bevat de resource-assemblies.

Ik heb het zowel lokaal op m'n pc getest, als vanop een andere pc en het werkt gewoon. Ik denk toch dat het moet te maken hebben met het feit dat je satellite assemblies op de een of andere manier niet toegankelijk zijn ofzo.

[Verwijderd]

whoami schreef op 14 februari 2004 @ 09:59:
Ik blijf het toch vreemd vinden hoor.

Ik heb het net even getest zoals in jouw situatie:
- een solution met een ASP.NET webapp project en een ClassLib project. Het ClassLib project bevat de resource-assemblies.

Ik heb het zowel lokaal op m'n pc getest, als vanop een andere pc en het werkt gewoon. Ik denk toch dat het moet te maken hebben met het feit dat je satellite assemblies op de een of andere manier niet toegankelijk zijn ofzo.

Je bedoeld dus dat je het via meerdere pc's op de server hebt getest?
Op deze manier werkt het bij mij lokaal ook wel.
Alleen als ik de software op een andere server installeer dan gebruikt deze de juiste resource maar de verkeerde taal (gewoon de basic zonder land toevoeging).
Terwijl dat deze wel is ingesteld en de resources zitten er ook bij in de juiste directories.

kZal nog wel is verder zoeken wat het kan zijn.

[Verwijderd]

Ik ben is verder gegaan met het onderzoeken van het en en ander waar mijn probleem uit voort kon komen.

Nu ben ik tot de volgende conclusie gekomen:

In de code zit het niet. Dat is duidelijk.

Maar als je de eigenschappen van een virtual directory bekijkt en dan het tabblad mapbeveiliging. Dan staat op dit tabblad anonieme toegang en verificatie methoden.
Nadat ik op servers waar de asp.net software op geinstalleerd stond op het betreffende tabblad het een en ander veranderde pakte deze wel de juiste taal.

Volgens mij ging het om anonieme toegang.

Heeft iemand hier een verklaring voor?
Dus bij de taal nl-NL werd gewoon test.dll gebruikt en niet test.nl-NL.resources.dll.
Voor de rest deed alles perfect.

Maar in ieder geval bedankt.