Dodatkowe uwagi
Poniższe sekcje zawierają dodatkowe uwagi dotyczące CMA.
Uwagi dotyczące transferu plików
Podczas przenoszenia pliku eksportu między systemami należy użyć opcji transferu binarnego dostępnej w narzędziu używanym do przenoszenia pliku, aby znaki na końcu wierszy nie były konwertowane ze stylu Linux na styl Windows i odwrotnie.
Zaleca się unikanie użycia rozszerzenia ".txt" pliku eksportu (zdefiniowanego w konfiguracji głównej). Takie rozszerzenie pliku domyślnie wskazuje na plik niebinarny, dlatego narzędzia wykonujące transfer pliku mogą go potraktować jako niebinarny, jeżeli nie będzie to jednoznacznie określone. Zalecane jest zdefiniowanie rozszerzenia ".cma". To rozszerzenie nie jest rozpoznawane, więc większość narzędzi do transferowania plików przeniesie plik w postaci bez zmian.
Należy zauważyć, że jeśli nastąpi konwersja pliku, prawdopodobne są dwa rezultaty - błąd konwersji numerycznej lub błąd niedopełnienia buforu podczas próby zaimportowania pliku.
Uwagi dotyczące środowiska wielojęzycznego
Jeśli we wdrożeniu używany jest język inny niż angielski, przenoszone obiekty administracyjne mogą mieć wiele wierszy języka (ponieważ język angielski jest zawsze włączony). Warto omówić kilka ważnych zagadnień związanych z wielojęzycznością w CMA:
-
Jak opisano w sekcji Język użytkownika, w przypadku obsługi dodatkowego języka należy wykonać określone kroki. Kroki omówione w tym temacie wskazują, że tłumaczenie ciągów danych systemowych może odbywać się za pomocą pakietu językowego dostarczonego z produktem lub może być realizowane w ramach wdrożenia. W każdym z przypadków zadanie to nie jest łatwe i opiera się na własnym, ustalonym planie. Oczekuje się, że tłumaczenie danych systemowych będzie realizowane dla każdego regionu w siedzibie wdrożenia. Nie należy używać CMA do tworzenia nowego języka w regionie docelowym.
-
W odniesieniu do danych administracyjnych/kontrolnych tworzonych we wdrożeniu jako część projektu oczekuje się, aby opisy obsługiwanego języka były wprowadzane w regionie uznawanym za region źródłowy i używanym do przekazywania zmian w regionach w "łańcuchu". Na przykład dane kontrolne są wprowadzane w regionie programistycznym i przekazywane na potrzeby testu z obsługiwanym językiem włączonym w obydwu regionach.
-
Co jeśli dane są eksportowane z regionu o włączonej większej liczbie języków niż w regionie docelowym? Ten scenariusz opisuje prawdopodobnie przypadek, w którym region źródłowy stanowi typ testu lub region testowy, gdzie dodatkowy język jest włączony w innych celach. W takiej sytuacji, jeśli dany kod języka w ogóle nie istnieje w regionie docelowym, import zakończy się błędem wskazującym, że kod ten jest nieprawidłowy. Jeśli kod języka istnieje, ale nie jest włączony, spowoduje to wstawienie dodatkowych wierszy języka do regionu docelowego, ale nie wywoła żadnych problemów. Zostaną one po prostu zignorowane.
-
Co jeśli dane są eksportowane z regionu o włączonej mniejszej liczbie języków niż w regionie docelowym? W takiej sytuacji, w procesie importowania zostaną utworzone wiersze tylko dla języków skopiowanych ze źródła. Nie spowoduje to automatycznego utworzenia wierszy języka w regionie docelowym w ramach importu. Dlatego zalecane jest uruchomienie programu zadania Nowy język (F1–LANG) służącego do tworzenia brakujących pozycji języka.