Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Błędy .NET w języku angielskim

Pisząc aplikacje w .NET często spotykamy się z wyjątkami (ktoś złośliwy mógłby napisać, że nie :P ). Dzięki polu Message w obiekcie Exception, dostajemy w postaci stringa opis błędu. Polski język nie jest obcy dla frameworku, co za tym idzie, wszelkie komunikaty otrzymujemy w naszej ojczystej mowie. Dużym plusem tego, jest możliwość "wyrzucenia" komunikatu z błędem, dzięki czemu każdy, bez znajomości języka angielskiego, może szybko (lub nie) zdiagnozować błąd.

Są jednakże i minusy. Otóż niektóre komunikaty błędów nie są tak oczywiste w języku polskim, jak w angielskim, co nie jest jeszcze dużym problemem. Większym problemem jest wyszukanie informacji (rozwiązania) o błędzie. Można być pewnym, że wpisując w google błąd w języku polskim, nie natrafimy na satysfakcjonujące nas rezultaty.

Powinniśmy zatem przetłumaczyć tekst na angielski i dopiero taki ciąg znaków szukać. I teraz zaczyna się "bajka". Wiadomo, iż tłumaczenia nie zawsze są jednoznaczne, ale co gorsze, można przecież dany zwrot przetłumaczyć na kilka sposobów.

Np. wyjątek w języku polskim:

Nie można odnaleźć wartości literału.

Można przetłumaczyć na:

Can not find the literal value.

Ale czy znajdziemy szybko, rozwiązanie? Niestety pewnie nie. Gdyż w oryginalnej wersji językowej (angielskiej) wyjątek ma opis:

Literal value was not found.

Zatem czy my, osoby korzystające z polskich komunikatów w .NET, jesteśmy na straconej pozycji? Oczywiście nie :)

Zmiana komunikatów z błędami w .NET na język angielski

Jest kilka wyjść, które pomogą nam uporać się z polskimi komunikatami z błędami w .NET.

FindErr.NET / Unlocalize

Gdy nie możemy/nie chcemy zmieniać komunikatów w oryginalnej aplikacji (bez naruszania kodu po stronie klienta/serwera), warto skorzystać ze strony FindErr.NET (http://finderr.net/), gdzie wystarczy wkleić komunikat w języku polskim, aby otrzymać oryginalną wersję w języku angielskim. Dostajemy również katalog, z możliwością przejrzenia/wyszukania zgromadzonych komunikatów. W taki oto sposób, łatwo wyszukamy źródłową wersję komunikatu w języku angielskim.

Podobną funkcjonalność oferuje Unlocalize: http://www.unlocalize.com

Zmiana bezpośrednio w wątku

Mając taką możliwość, podmianę języka komunikatów można zrobić wstawiając do kodu:

Thread.CurrentThread.CurrentCulture = new CultureInfo("en-us"); Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture;

Zmiana w web.configu

Jeśli chcemy w naszej aplikacji ASP.NET zmienić język komunikatów z błędami na np. angielski, wystarczy dodać do web.configu w sekcji <system.web> : <globalization culture="en-US" uiCulture="en-US" />

Oczywiście jest jeszcze możliwość odinstalowania "spolszczeń" do .NETa i/lub zabawy z językiem w systemie, jednakże nie zawsze te chwyty działają. A wymienione wyżej wyjścia pozwolą w miarę szybko i bezstresowo uporać się z angielskimi komunikatami w .NET. 

porady programowanie

Komentarze

0 nowych
alucosoftware   7 #1 17.04.2012 20:03

Powinni tego zabronić! - mam na myśli komunikaty w wyjątkach w ojczystym języku. Ale lepsze to niż zrzut StackTrace kodu po obfuskacji :)

BTW wysłane dziś po południu...

djfoxer   17 #2 17.04.2012 22:30

@alucosoftware
A serdecznie dziękuję :)

matzu   5 #3 18.04.2012 19:05

Fajna stronka, na pewno się przyda. Mam pytanie co do wpisu, a konkretnie do alternatywnej metody zmiany języka komunikatów wyjątków. Interesuje mnie czemu każesz zmieniać wartość CurrentCulture. Przecież to nie jest potrzebne.

matzu   5 #4 18.04.2012 19:14

Dodam jeszcze tylko jedną rzecz. W tym wypadku nie ma to wprawdzie, aż tak dużego znaczenia, ale już w sytuacji pisania aplikacji wielojęzycznej może się przydać. Zamiast tworzyć nową instancję CultureInfo powinno się używać CultureInfo.GetCultureInfo.

djfoxer   17 #5 18.04.2012 20:28

@matzu
Cieszę się, ze poruszyłeś ten temat :)

Warto zmienić zarówno CurrentCulture jak i CurrentUICulture. Dlaczego? W skrócie, CurrentCulture odpowiada za formatowanie dat, przecinków/kropek w liczbach itp. CurrentUICulture związane jest z tekstem, tłumaczeniem z np. plików Resource. Jeśli wyrzucasz oprócz treści wyjątku np. datę, czy liczbę zmiennoprzecinkową, walutę itp., wówczas będziesz miał tekst w jednej "kulturze".

Jest to ważne np. w takiej sytuacji:
Załóżmy, że w "catch (Exception e)" dodamy:
Console.WriteLine(e.Message + " "+ DateTime.Now.ToShortDateString());

Ustawiając:
CurrentCulture = CurrentUICulture = "en"
otrzymamy:
"Attempted to divide by zero. 4/18/2012"

Ustawiając:
CurrentUICulture = "en"
otrzymamy:
"Attempted to divide by zero. 2012-04-18"


Wówczas otrzymujemy komunikaty w jednolitym formacie. Chociaż trzeba pamiętać co robimy. Jeśli mamy parsowanie decimala bez patrzenia na CurrentCulture (czyli źle, jakby nie patrzeć), to może nam się popaćkać. W taki sposób można również szybko sprawdzić, czy nasza aplikacja nie będzie miała problemu z rożnymi wersjami językowymi systemu.


CultureInfo.GetCultureInfo - w większych aplikacjach to faktycznie dobry zwyczaj :)

matzu   5 #6 18.04.2012 23:08

@djfoxer
Ogólnie rozumiem chęć uzyskania jednolitego fomatu wyjątku, ale mam wrażenie, że coś mogłeś przeoczyć. Piszę "mogłeś", bo nie przychodzi mi do głowy teraz żaden konkretny przykład (i tym samym możliwe, że nic nie przeoczyłeś).

Co jeśli wyjątek wynikał właśnie z ustawień kulturowych aplikacji, dodatkowo zmodyfikowanych przez użytkownika w wyniku grzebania w panelu sterowania? Zmieniasz teraz CurrentCulture na pałę na np. en-US i nagle magicznie wyjątek znika, i komunikatu już nie można odczytać.

BTW przypisując ustawienia kulturowe (a konkretnie CurrentCulture) zaleca się używanie "specific culture", a nie "neutral culture" (nie wiem jak to się tłumaczy na polski), czyli samego "en" nie powinno się używać. Jeśli w przykładzie zawarłeś to z pośpiechu, to może komuś innemu się ta informacja przyda.

djfoxer   17 #7 18.04.2012 23:53

@matzu
Np. do parsowania można użyć CultureInfo.InvariantCulture, wówczas jesteśmy uniezależnieni od CurrentCulture. Warto też ustawić CurrentCulture = CurrentUICulture, gdyż np. DateTime.Now.ToShortDateString() dla EN i FR jest identyczne tylko miesiąc z dniem są przestawione i wówczas odczytanie 4/1/2012 może być już kłopotliwe :)

W komentarzu "en" dałem jako skrót myślowy, we wpisie zobacz, że wszędzie dałem już en-US. Ogólnie temat niby błahy, ale ciekawy :)

  #8 23.04.2012 10:02

Duży plus za zwrócenie uwagi na problem. A tego, kto te komunikaty wyjątków tłumaczył to należałoby za jaja za przeproszeniem powiesić, jak czasem to czytam to ręce opadają.

  #9 18.05.2012 17:37

Ostatnio podczas pisania programu do pracy dyplomowej, VS nie omieszkał poczęstować mnie wieloma spolszczonymi błędami. Niektóre łatwo było rozszyfrować, ale inne to było zadanie dla...wytrawnego detektywa. Długo musiałem szukać po zakamarkach internetu, by po kilku godzinach zaleźć to czego potrzebowałem. Teraz już nie będę musiał się tak męczyć. Bardzo dziękuję za ciekaw wpis ;-)