Nazywanie kluczy w pliku najlepszych praktyk

Question

Czy ktoś ma jakieś zalecenia dotyczące nazywania kluczy w plikach zasobów? Na przykład, czy nazwa twojego klucza jest podstawą do tekstu, który musi być zlokalizowany lub do formantu, który używa tekstu?

Załóżmy, że masz przycisk edycji na kilku ekranach (jeden do edycji użytkownika, a drugi do edycji grupy). Można użyć następujących klawiszy:

• editUserButton.label = Edytuj użytkownika ...
• editGroupButton.label = Edit Group ...

lub

• editUser = Edytuj Użytkownik ...
• editGroup = Edytuj grupę ...

lub

• user.edit = Edytuj użytkownika ...
• group.edit = Edit Group ...

Co schemat wolisz i dlaczego?

Answer 1

Przedrostkiem moich literałów jest użycie lub nazwa klasy akcji. np:

PlaceOrder.invalidId=Invalid id for order {0} 
PlaceOrder.success=Your order {0} was successful 
PlaceOrder.fail.visa=Your visa was ... 
PlaceOrder.fail.communications=We could not... 
PlaceOrder.submit=Buy now 

Login=Login 
Login.fail=Your credentials did not... 
Login.alread=You are already logged in

W ten sposób można uniknąć kolizji:

EditStudent=Edit 
EditClass=Edit 
EditCourse=Edit Course

... a także może znaleźć to, czego potrzebujesz łatwiejsze.

Innym sposobem I grupa jest przez podmiot:

Person.id=# 
Person.name=First name 
Person.surname=Surname

Mogą pojawić się jako nagłówki na stołach z podmiotów. To oszczędza w takich przypadkach:

Person.id=# 
Class.id=# 
Course.id=Course Id

Wreszcie poprzez podanie kontekstu w kluczach właściwości można zapisać się od fałszywych tłumaczeń. Na przykład ja kiedyś:

no=no

który był używany jako cel id (#) na stole górnym lewym komórce, ale nasz francuski tłumacz zrobił dla języka francuskiego:

no=non

... myślał, że to słowo "nie" (negatywne tak). :)

Ostatni (ale nie najmniej) prefiks z nazwą klasy pomoże ci, gdy chcesz refactorować/zmieniać nazwy klas i szybko aktualizować te klucze właściwości bez konieczności przeglądania szablonów.

Answer 2

Uważam, że przede wszystkim należy użyć plików XML do przechowywania tego rodzaju danych.

Coś jak:

< xml version = "1.0" encoding = "UTF-8" standalone = "yes"? >
< xml >
        < przycisk >
                < edit >
                        < użytkownik > *** Edit User * </user >
                        < grupa > Edytuj grupę </grupa >
                </edit >
        </przycisk >
</xml > **

a następnie użyć "przetłumaczyć" Class dostać (i ustawić/zapis) tekst.

podobnie jak:

myTranslateClass.load ('translate.xml');
myTranslateClass.get ("przycisk", "edytuj", "użytkownik");

To prosty przykład.

Answer 3

Bazujemy na angielskiej wersji tego terminu. Np .: EditUser To było łatwe do odczytania przez naszych programistów i można je ponownie wykorzystać w wielu lokalizacjach, które to określenie jest wymagane w całej aplikacji.

Answer 4

Oprzyj go na tekście angielskim, ale prefiks z oknem/dialogiem/tym, co masz, w którym pojawia się słowo lub fraza. Przynajmniej wtedy, gdy przestrzeń w układzie jest ograniczona, możesz chcieć uniknąć wpadnięcia w pułapkę posiadania dokładnie tego samego ciągu wszędzie: to powstrzyma cię od skrótu, aby uzyskać przyzwoite układy, szczególnie w językach wielosylabowych, takich jak fiński.

Oczywiście nadal powinieneś dążyć do konsekwentnego nadawania nazw. Zwiększenie liczby łańcuchów zwiększy również koszty tłumaczeń, jeśli robisz to komercyjnie.

I nie ignoruj ​​zagrożenia homonimami. Zapewnienie kontekstu pomaga temu zapobiec. Nie bój się, aby nazwa zasobu była dłuższa niż nazwa angielska, co może pomóc tłumaczom w znacznym stopniu.

Answer 5

+1 za odpowiedź @ cherouvima, ale zawsze sprowadza się do dokumentacji.

Dokumentuj każdą wartość (używając dowolnego mechanizmu komentarzy obsługiwanego przez format pliku źródłowego zasobów), w tym typ danych każdego parametru, jeśli ciąg znaków jest niemożliwy do sformatowania. Na przykład edytor VS dla formatu .resx udostępnia pole komentarza, co czyni go bardzo łatwym.

Więc jak się komunikat:

Nie można zaplanować {0} pracę przed {1}.

byłyby udokumentowane jako coś w rodzaju:

wiadomości Zalogowany błędu {0}: tytuł pracy, {1} data/czas w formacie ISO 8601.