Jak zarządzać zadaniem sprawdzania zlokalizowanych ciągów przez programistę?

W .NET Framework zlokalizowane ciągi znajdują się w pliku XML (lub wielu plikach). Pliki te są częścią projektu i podlegają kontroli źródła, tak jak każdy inny plik kodu źródłowego. Zazwyczaj program Visual Studio służy do wyświetlania tych plików jako tabeli i edycji zlokalizowanych ciągów.

Pracuję w małym zespole nad produktem, który powinien mieć wielojęzyczny interfejs.

1. Jako programista szkicuję zlokalizowane ciągi w obu językach, biorąc pod uwagę, że tłumaczenie może być niedokładne,

2. Inna osoba z zespołu (nie-programista) sprawdza treść w obu językach i poprawia ją w razie potrzeby.

Obecny problem polega na tym, że osoba niebędąca programistą nie użyłaby ani kontroli źródła, ani IDE, ponieważ byłoby to zbyt kłopotliwe i trudne (kontrola wersji jest trudna dla nie-programistów) dla tej osoby.

Alternatywnym rozwiązaniem byłoby wyeksportowanie zlokalizowanych ciągów jako pliku Excela, poczekaj, aż ta osoba przejrzy Excela, a następnie ponownie zaimportuj zmodyfikowane ciągi. Zastrzeżenie polega na tym, że mogę tworzyć inne ciągi, zmieniać nazwy istniejących, itp., Co utrudnia różnicowanie wersji lokalnej z recenzowaną.

Co robić?

Jak to się dzieje w innych zespołach?

Lokalizacja jest o wiele bardziej złożona niż edycja XML w Visual Studio, w szczególności:

1. Chociaż to, co mówi KateGregory , jest poprawne, Visual Studio jest drogie, a kupowanie kopii dla lokalizatorów jest często zabronione.
2. O ile lokalizator nie jest również programistą, nie może zobaczyć ciągów w produkcie i przetestować, czy są one wyświetlane poprawnie (znaki pozaeuropejskie, takie jak języki azjatyckie lub tekst od prawej do lewej, np. Arabski), poprawnie pasują / zawijają (długi niemiecki słów) i nie powodują ataków iniekcyjnych (takich jak apostrofy Francuzów)
3. Chociaż kontrola wersji nie jest złożonym narzędziem, zapewnienie dostępu do kontroli źródła zdalnym lub zakontraktowanym lokalizatorom stanowi ryzyko. Mogą kopiować kod źródłowy bez wiedzy zespołu lub dokonywać przełomowych zmian (celowo lub nieumyślnie).
4. Zakłada się również, że lokalizujesz tylko pliki RESX. Niektóre produkty mogą mieć zlokalizowane dane, takie jak nazwy raportów.

Dlatego najlepiej jest utworzyć prostą stronę internetową, która ujawnia różne ciągi, ukrywając podstawową składnię. Proces kompilacji obejmuje ciągi znaków dostarczone przez lokalizatory po szybkim sprawdzeniu poprawności i kompilację udostępnioną lokalizatorom do testowania. Witryna może używać danych logowania do różnych lokalizatorów (i śledzić i rozliczać pracę, jeśli chcesz zajść tak daleko). To więcej pracy, ale lepsze rozwiązanie w dłuższej perspektywie.

Edycja XML jest do bani. Visual Studio ma widok, którego możesz użyć do edycji zasobów:

Uważam, że wymeldowanie przy edycji w połączeniu z minutą zademonstrowania okna „oczekujących zmian” powinno umożliwić nie-programistom korzystanie z takiej kontroli źródła, ile potrzeba.

Chciałbym znaleźć edytor XML * do użycia przez programistów.

Następnie musisz dostarczyć wersjonowane wyciągi do nie-programisty do sprawdzenia.

Po zakończeniu przeglądu możesz ponownie sprawdzić plik.

Po dokonaniu zmian musisz po prostu różnicować pliki XML przed odprawą i wysłać zaktualizowane sekcje do osoby niebędącej programistą w celu sprawdzenia. Twoje aktualizacje są powodem, dla którego musisz zachować wersjonowanie plików recenzji.

Próba użycia programu Excel sprawi, że będzie to niezwykle trudne, ponieważ narzędzia różnicujące do programu Excel pozostawiają wiele do życzenia. Ryzykujesz także, że dodatkowe komentarze wkradną się do dodatkowych komórek w arkuszu kalkulacyjnym. Te komentarze wymagałyby dodatkowego postępowania z Twojej strony, aby je ponownie połączyć.

W poprzednim życiu stosowaliśmy dość podobny proces w przypadku szeregu tłumaczeń przez organizacje zewnętrzne. Nasze pliki były zasadniczo plikami tekstowymi o podobnej, ale innej formie niż XML. I mieliśmy mnóstwo zmian, gdy pliki były sprawdzane, więc doceniam zabawę z twojej sytuacji.

Jedną z opcji jest utworzenie aplikacji pomocniczej, w której tłumacz może zobaczyć listę ciągów znaków w jednym okienku i wprowadzić język specyficzny w innym. W ten sposób dane są zapisywane z powrotem do pliku XML, dzięki czemu aplikacja może wyeksportować plik.

Jeśli przetwarzasz klucze do bazy danych i przechowujesz tam każdy język, pozwoliłoby to na zintegrowanie zmian i przetłumaczenie przez tłumacza potrzebnych aktualizacji. Następnie możesz po prostu wyeksportować do pliku XML określonego języka, który ponownie umieścisz w kontroli wersji lub może to zrobić tłumacz.

Używamy podobnej metody do tego z naszym kodem Rails, nigdy nie edytujemy ani nawet nie dostarczamy plików specyficznych dla języka, wszystkie są utrzymywane, a następnie eksportowane przez zewnętrzną aplikację, z której korzysta nasz zespół tłumaczący. Przepraszam, nie wiem, czy ich oprogramowanie jest niestandardowe, czy gotowe, ale nie powinno być tak trudno złożyć coś prostego.

Skąd wiesz, że masz wszystkie ciągi i że są one poprawnie sformatowane w aplikacji? Skąd wiesz, że liczby, waluta, strefa czasowa i inne informacje regionalne są poprawnie sformatowane? Czy wszystko jest załadowane i serializacja wielobajtowa działa poprawnie?

Nie. Lokalizacja to funkcja jak każda inna. Sprawdź to. Zrób kompilację. Pozwól testerowi uzyskać kompilację i sprawdź, czy funkcja została wykonana poprawnie, jak każda inna. Kiedy tworzysz nową kompilację, musisz wykonać testy regresji lokalizacji - tak jak każda inna funkcja.