2009-09-22 11 views
6

Przed .NET, mieliśmy własny system lokalizacji fraz i skonstruowaliśmy w taki sposób, aby komentarze były zagnieżdżane w ciągu formatującym, np .: "{0: price}". Zauważyłem, że tęsknię coraz bardziej w miarę upływu lat..NET Tworzenie ciągów znaków - dobre praktyki do komentowania?

Nie wydaje się, że istnieje sposób, aby udokumentować formatowania ciągów in situ jak to w .NET:

string.Format("{0//numerator}/{1//denominator} = {2//ratio}" 
       ,somevar 
       ,anothervar 
       ,yetanothervar); 

W szczególności jest to przydatne w lokalizacja/frazeologii gdzie punkty wstawienia się kolejność, bez zmiany kodu:

string.Format("Dividing {1//denominator} into {0//numerator} gives {2//ratio}" 
       ,somevar 
       ,anothervar 
       ,yetanothervar); 

ktoś ma żadnych sztuczek, których używają w celu udokumentowania ich uniknąć błędów, gdy warunki się przegrupowaniu w konserwacji/lokalizacji itp?

Powód, dla którego komentowanie jest ważne, polega na tym, że w przypadku lokalizacji i konfiguracji typowy ciąg nie znajduje się w kodzie ze zmiennymi - mam je w plikach zasobów, w pliku app.config iw bazach danych.

W rzeczywistym przykładzie kontrolka z podklasą udostępnia właściwość PhraseID (formanty są odwzorowywane na identyfikatory w pliku XML wygenerowanym z formularza, a formanty formularza są tłumaczone w locie), więc formularz podklasowany wykonuje coś takiego :

// Handle the phrases without insertion points - this is in the base class 
foreach (Control in this.Controls) { 
    IXLatable ixl = (IXLatable) Control; 
    ixl.Text = GetPhrase(ixl.PhraseID); 
} 

// in the individual form classes, they override the behavior for complex displays: 
lnkPublish.Text = string.Format(GetPhrase(lnkPublish.PhraseID), filename, foldername, userid); 

jeżeli Słownik zawiera domyślne i zlokalizowaną ciąg jak:

phraseid, language code, phrase 
1,en,"{0//filename} published to {1//foldername} by {2//userid}" 
1,pl,"{2//userid} ublishedpay ethay ilefay {0//filename} otay {1//foldername}" 

jest dużo mniej prawdopodobne, że tłumacz (kto nigdy nie widzi kodu źródłowego) dostaną indeksy źle, jeśli są one dostarczone z komentarzami w d zdanie efault. I łatwiej dla nie-zlokalizowanego głośnika rozwiązywać problemy z przetłumaczonym zasobem.

+0

nie .NET, ale format wiadomości jest dość ciekawa lokalizacja mądry https://github.com/jedtoolkit/messageformat.js –

Odpowiedz

4

Można by spojrzeć na Phil Haack's NamedFormat extension, który pozwala na korzystanie z formatów jak

NamedFormat("{{{foo}}}", new {foo = 123}) 
+0

Jestem zadowolony z użycia pozycyjnego, ale to jest interesujące. Wyobrażam sobie, że możliwe są gorsze problemy w czasie wykonywania z nazwanym użyciem. –

2

W twoim przykładzie nazywanie zmiennych znaczącymi, będzie miało taki sam wpływ jak komentarze.

+1

Że Okazuje się, że nie ma to miejsca w nietrywialnych przykładach. –

Powiązane problemy