Jak zorganizować zasoby ciągu lokalizacji?

Tworzymy dużą aplikację, składającą się z wielu małych pakietów. Każdy pakiet ma własny zestaw plików zasobów do lokalizacji.

Jakie jest najlepsze podejście do organizowania i nazywania ciągów lokalizacji?

Oto moje dotychczasowe przemyślenia:

Obsługa duplikatów

Ten sam tekst (powiedzmy „kod pocztowy”) może występować wiele razy w ramach danego pakietu. Instynkt programistyczny (DRY) każe mi utworzyć pojedynczy zasób łańcucha, który będzie współużytkowany przez wszystkie wystąpienia .

Z drugiej strony tłumacz może chcieć wybrać długie tłumaczenie („Postleitzahl”) w niektórych miejscach i krótsze („PLZ”) w miejscach o mniejszej przestrzeni. Lub możemy zdecydować o dołączeniu dwukropka do niektórych wystąpień („Kod pocztowy:”), ale nie do innych. Lub może wymagać innej litery („kod pocztowy”) w niektórych miejscach. Wszystkie te argumenty wskazują na utworzenie jednego zasobu na użycie, nawet jeśli ich zawartość jest identyczna .

Nazewnictwo

Jeśli naszym celem jest wyeliminowanie duplikatów, sensowne jest nazwanie zasobów według zawartości , być może wskazując na rodzaj użycia za pomocą prefiksu. Więc możemy mieć labelOK= "OK" , messageFileTooLarge= "Plik przekracza maksymalny rozmiar pliku." i labelZipCode= „Kod pocztowy” .

Nazywanie według zawartości ma tę zaletę, że naturalnie obsługuje argumenty formatu: zasób messageFileHas_0_MBWhileMaximumIs_1_MBwyraźnie przyjmuje dwa argumenty formatowania, rzeczywisty rozmiar pliku i maksymalny rozmiar pliku.

Jeśli pozwolimy na duplikaty, nazywanie samych treści nie ma sensu. Aby uzyskać unikalne nazwy zasobów, musimy jakoś zawrzeć miejsce użycia w nazwie zasobu. Działa to w przypadku kontrolek graficznych, chociaż identyfikatory mają tendencję do wydłużania się: fileSelectionConfirmationButtonText= „OK” , customerDetailsTableColumnZipCode= „Kod pocztowy” . Jednak w przypadku plików kodu niewizualnego jest trudniej. Jak nazwać określone użycie łańcucha, jeśli nie wiesz, gdzie ostatecznie zostanie wyświetlone? Według pliku kodu i nazwy funkcji? Wydaje mi się raczej niezdarny i kruchy.

Podsumowując, skłaniam się ku dopuszczeniu duplikatów, ale staram się znaleźć spójny schemat nazewnictwa, który to obsługuje.

Edycja: To pytanie ma dwa aspekty: Jak organizować zasoby (DRY vs. duplikaty) i jak je nazwać . Jak dotąd odpowiedzi koncentrowały się na pierwszym aspekcie. Byłbym wdzięczny za opinie dotyczące konwencji nazewnictwa!

Zaakceptowałbym powielanie, ilekroć nie możesz być absolutnie pewien, że znaczenie jest dokładnie takie samo we wszystkich przypadkach, gdy używany jest określony ciąg.

Nawet jeśli dwie etykiety zawsze zawierają ten sam ciąg w języku angielskim (lub języku ojczystym), niekoniecznie będą takie same we wszystkich językach. Zaakceptowanie powielania może dać (a raczej tłumaczom) elastyczność potrzebną do poradzenia sobie z takimi sytuacjami.

Jako przykład: rozważ etykietę „Warunek”, która - w zależności od kontekstu - może zostać przetłumaczona na „Zustand” lub „Bedingung” w języku niemieckim (wśród wielu innych możliwych tłumaczeń).

Zaakceptuj niektóre duplikaty.

Można uniknąć wielu tłumaczeń, tworząc dodatkowe elementy sterujące. Np. A CancelButtoni an, OKButtonktóre już zawierają ich tekst, a teraz Cancel / Abbrechen OK / OK należy przetłumaczyć tylko raz. Ale to prawie wyjątkowy przypadek.

W ten sposób radzimy sobie z tym w mojej firmie:

Konwencja nazewnictwa: Nadajemy nazwy etykietom, poprzedzając je ich klasą / sekcją / formą itp. Na przykład loadFile_loadButton, loadFile_fileNameLabel, loadFile_cancelsą wszystkie etykiety należące do dialogu ładowania pliku. Chociaż ta podkreślona konwencja nazewnictwa nie jest najczęstsza, preferujemy ją w stosunku do bardziej standardowych konwencji, ponieważ poprawia czytelność i „grupowalność”: zauważ, jak łatwo jest zobaczyć, do którego elementu należą etykiety i co reprezentuje każda etykieta, w porównaniu do etykiet nazwany loadFileLoadButton, loadFileNameLabeli loadFileCancel. Możesz myśleć, że różnica nie jest tak duża, ale gdy masz tysiące etykiet, efekt złożony jest tego wart.

Komentarze nagłówka: Oprócz prefiksów nazw etykiet dodajemy również komentarze „nagłówków” do plików zasobów, aby jasno zdefiniować grupy etykiet. W ten sposób ktoś, kto chce zmodyfikować lub dodać określone etykiety związane z jedną konkretną klasą / sekcją / formularzem itp., Może znaleźć wszystkie etykiety powiązane z tym konkretnym elementem w jednym miejscu, pod jednym nagłówkiem, i może łatwo łatwo dodawać lub modyfikować etykiety wiedząc, że nie będą łamać tłumaczeń dla żadnych innych elementów (IMHO, jest to również bardzo mocny argument, dlaczego należy zezwolić na powielanie).

Pożądane są „uzasadnione” duplikaty: jak wspomniano powyżej, praktyki te ostatecznie doprowadzą do zduplikowania etykiet, ale nie widzimy z tym problemu (więcej o tym, jak sobie z tym poradzić w Narzędziach handlu).

Jak zauważyli inni, jedną etykietę w jednym języku można przetłumaczyć na dwa lub więcej różnych sposobów na inne języki, w zależności od kontekstu, w jakim są prezentowane. Jeśli „ujednolicisz” etykiety, tłumaczowi będzie naprawdę ciężko wymyślić jedną etykietę, która będzie pasować do wszystkich kontekstów, w których się znajduje. Tak więc, jak widzimy, zezwolenie na „uzasadnione” duplikaty pomaga poprawić jakość lokalizacji, o ile nie odnoszą się do tej samej rzeczy w tym samym kontekście (jest to znaczenie „uzasadniony”).

Narzędzia handlu: aby być jak najbardziej efektywnym podczas tłumaczeń, możesz zbudować własne narzędzie, które szuka podobnych etykiet, które istnieją w twoich pakietach, i oferuje ich tłumaczenia jako wartości domyślne dla nowych etykiet, a nawet możesz skorzystaj z istniejących usług takich jak ta , które zapewniają narzędzia takie jak te, o których właśnie wspomniałem, dzięki czemu tłumaczenie nowych etykiet jest dziecinnie proste (tym bardziej, że są one powtarzane kilka razy, ponieważ narzędzie oferuje domyślnie kilka opcji tłumaczenia dla nowych etykiet ).

Podsumowując: uzasadnione powielanie i grupowanie etykiet w sposób kontekstowy naprawdę pomaga tłumaczom wykonywać swoją pracę. Wielki czas. Pomyśl tylko o tym: kontekst ma wiele do zaoferowania tłumaczowi w wyborze właściwego tłumaczenia. A zezwolenie na „uzasadnione” duplikaty eliminuje konflikt polegający na konieczności wybrania jednego tłumaczenia, które źle pasuje do niektórych kontekstów (ale i tak jest ogólnie najlepsze).

Mam nadzieję, że to pomoże!

Kiedy robiłem to w przeszłości, poszliśmy ścieżką pliku zasobów zawierającego pełne zdania. Gdyby dokładnie to samo zdanie było używane wielokrotnie, ale jeśli byłyby to tylko pojedyncze słowa z jednego zdania, słowa te zostałyby powielone.

Byliśmy przywiązani do frameworka, w którym plik zasobów zawierał tylko listę angielskich fraz, a następnie tłumaczenie (z niektórymi danymi indeksującymi na końcu do szybkiego wyszukiwania).

W przypadku małych monitów lub przycisków danych, takich jak nazwa pola „Kod pocztowy” lub przycisk „OK”, zapisuje ciąg „Kod pocztowy”, a następnie tłumaczenie i użyje go wszędzie tam, gdzie wymagany jest cały ciąg. Ale (chyba że ręcznie zerwaliśmy łańcuch) nie użyłby go do wyświetlania „kodu pocztowego” w zdaniu.

Korzystając z przykładu kodu pocztowego, jeśli spróbujesz przetłumaczyć go samodzielnie i zastąpić go we wszystkich zdaniach, które go używają, otrzymasz bardzo złe tłumaczenie.

Na przykład „Kod pocztowy musi zostać wprowadzony” może wymagać przetłumaczenia dosłownego odpowiednika „Wprowadzony kod pocztowy musi być” na inny język. Jeśli podzielisz zdanie, nie otrzymasz odwrócenia słów wymaganych w innym języku.

Dlatego niektóre źle wykonane tłumaczenia na angielski wyglądają tak absurdalnie, że osoba, która to robi, tłumaczy tylko poszczególne słowa, a nie całe zdanie.

Zawsze uważaliśmy, że najlepiej tłumaczyć zdania jako całość, bez ich rozbijania. Mieliśmy symbole zastępcze dla danych, które wymagały wstawienia (np. „Numer części @ 1 jest zbędny”), a tłumacz mógł przenieść symbol zastępczy do żądanej pozycji, aby uzyskać dobre tłumaczenie.

Okazało się jednak, że zezwalanie na miejsca, w których użyto dokładnie tego samego zdania, tego samego monitu o dane lub tej samej etykiety przycisku itp., Było w porządku, aby udostępniać tłumaczenia. To nigdy nie stanowiło problemu i oszczędzało czas / koszty tłumacza.

Twoje myślenie o nazywaniu jest dobre.

Cele

• Zdefiniuj wspólną etykietę (tj. Nazwę zmiennej) dla zlokalizowanego tekstu.
• Etykieta powinna mieć „wielkość umysłu”. To jest ... tak krótko praktyczne, a jednocześnie jednoznaczne.
• Etykiety powinny mieć spójny format, aby zmaksymalizować przewidywalność i przywołanie.

Realizacja

• Zmniejsz obciążenie poznawcze dzięki konsekwentnemu stosowaniu dobrze znanych skrótów (np. Msg = wiadomość, lbl = etykieta, btn = przycisk, ...)
• Narzędzia prezentują zmienne / etykiety na listach alfabetycznych, więc wyszukiwanie ludzi jest najlepsze, gdy powiązane etykiety grupują się razem. Uczyń nazwy hierarchicznymi od najbardziej ogólnych do najbardziej szczegółowych. (tj. msgFileMissing, msgFileSaved, msgFileDeleted).
• Angielski jest językiem uporządkowanym czasownik-rzeczownik. Wiele (większość?) Innych języków to czasownik rzeczownik. Czasownik rzeczownik działa najlepiej w przypadku grupowania hierarchicznego.