Platforma low-code Ferryt 2.0 pozwala w wygodny sposób zarządzać kontekstem językowym formularzy i procesów, które są na niej budowane. Domyślnym językiem jest tutaj język polski – występuje on we wszystkich miejscach, np.:
- w podstawowych komunikatach walidacyjnych (np. „Pole jest wymagane”, „Do pola proszę wprowadzić co najmniej 6 znaków”);
- komunikatach systemowych (np. „Prosimy o kontakt z administratorem”);
- w kontrolkach (np. „Zwiń/Rozwiń” dla etykiet lub regionów z opcją rozwijania, nazwy miesięcy w Kalendarzu).
Czym jest CultureInfo
Developer pracujący w Ferryt 2.0 może sprawdzić bieżący kontekst językowy na wniosku poprzez użycie prostego polecenia:
CF.Comments = USER.Current.CultureInfo;
Otrzyma on wtedy informację o „Culture Info”. Jest to pojęcie w programowaniu, które służy do reprezentowania informacji uwzględniając różnice kulturowe w prezentacji danych, takich jak liczby, daty, waluty czy teksty.
W zakres „Culture Info” wchodzą m.in. formatowanie liczb (separator dziesiętny), formatowanie dat i godzin (kolejność dnia, miesiąca, roku; format 12- lub 24-godzinny) czy właśnie język.
Język polski oznaczony jest jako „pl-PL”. Jest to forma zapisu wynikająca ze standardu kodów języków i regionów w informatyce – IETF BCP 47 (wcześniej RFC 4646). Pierwsza część („pl”) oznacza język (dwuliterowy kod ISO 639-1), druga zaś („PL”) odpowiada za region/kraj (kod ISO 3166-1 alpha-2).
Praktyczny przykład i zastosowanie:
var plPL = new CultureInfo("pl-PL"); --> polski-Polska
var plUS = new CultureInfo("pl-US"); --> polski-Stany Zjednoczone
double liczba = 12345.67;
//formatowanie daty
Console.WriteLine(DateTime.Now.ToString(plPL)); --> otrzymamy 09.12.2025 14:05:00
Console.WriteLine(DateTime.Now.ToString(plUS)); --> otrzymamy 12/09/2025 2:05:00 PM
//formatowanie liczby
Console.WriteLine(liczba.ToString("N", plPL)); --> otrzymamy 12 345,67
Console.WriteLine(liczba.ToString("N", plUS)); --> otrzymamy 12,345.67
//formatowanie waluty
Console.WriteLine(liczba.ToString("C", plPL)); --> otrzymamy 12 345,67 zł
Console.WriteLine(liczba.ToString("C", plUS)); --> otrzymamy $12,345.67
Najpopularniejszy język obcy to bez wątpienia język angielski, który w „Culture Info” w Ferryt 2.0 obsługiwany jest jako „en-GB”.
Aby uruchomić wniosek w języku innym niż domyślny (polski) należy w linku przekazać parametr „lang”, podobnie jak przekazywać możemy wartości do Pól Wspólnych (Common Fields) dopuszczonych w Ferryt Linku.
Przykład:
– domyślny adres (zgodny ze zdefiniowanym prefixem w Ferryt Linku) dla eWniosku na platformie Ferryt 2.0:
https://serwer/FerrytCore/ABC
– ten sam eWniosek z językiem zmienionym na angielski:
https://serwer/FerrytCore/ABC?lang=EN
Należy w tym miejscu zwrócić uwagę, iż przekazywanie parametrów w linku zawsze rozpoczynamy od znaku „?”. Jeżeli parametr „lang” jest jednym z kilku, używamy wtedy znaku „&”:
– ten sam eWniosek z językiem zmienionym na angielski oraz innym parametrem:
https://serwer/FerrytCore/ABC?FieldString1=FerrytCommunity&lang=EN
Dla języka domyślnego nie trzeba przekazywać parametru w ogóle (np. dla polskiego „lang=PL”).
Z poziomu ADMINA w Konfiguracji parametrów systemu developer może określić:
- System.Cultures (domyślnie „pl-PL,en-GB,de-DE”) – dla obsługiwanych kontekstów językowych
- System.DefaultCulture (domyślnie „pl-PL”) – dla głównego kontekstu językowego
Jak konfigurować procesy i ekrany?
Developer tworzący procesy może wykorzystać „Culture Info” jako warunek, na przykład na potrzeby nadawania wartości dla pól.
Przykład:
if (
USER.Current.CultureInfo == "en-GB"
) {
PF.poletekstowe = "This value comes from the flow - culture info en-GB";
else {
PF.poletekstowe = "ta wartość pochodzi z flow - culture info domyślne pl-PL";
}
Najczęściej jednak niezbędne prace przyjmą formę działań w Edytorze Ekranów Architekta Ferryt 2.0. W tym miejscu bowiem developer może określać konteksty językowe per kontrolka.
Przykład:
Mając zaznaczoną kontrolkę typu „pole tekstowe”, chcemy określić jej placeholdery. Klikamy w symbol wielojęzyczności (zaznaczone na czerwono); kolejno ukazuje się okienko edycji:

Klikamy w „+” i tym samym możemy już dodać nowy język:

Wybrawszy kontekst językowy, wprowadzamy tekst i zapisujemy go:

Następnie zapisujemy Ekran i tym samym wprowadzamy nasze zmiany w życie.
Jeżeli wartość nie zostanie nadana (np. w wyniku błędu ludzkiego) a proces uruchomimy w wersji angielskiej, to domyślnie podstawi się wartość w języku polskim – takie działanie ma zastosowanie do wszystkich możliwych do edycji kontrolek.
Niektóre z kontrolek nie wymagają żadnych działań ze strony low-code developera, gdyż automatycznie dopasowują się do języka procesu – za przykład może posłużyć Kalendarz:

Nazwy miesięcy podstawiają się automatycznie i nie potrzeba dodatkowej konfiguracji z poziomu Architekta Ferryt 2.0.
Jeżeli low-code developer zamierza tworzyć procesy posiadające 3 warianty widoków (desktop/tablet/mobile), może szybko nadawać wartości wielojęzyczne kontrolkom dla każdego z widoków pod warunkiem, że te na każdym z widoków mają taki sam Symbol.

Przykład:
Mając otwarte wszystkie 3 kłódki, na dowolnym z widoków kładziemy kontrolkę „pole tekstowe”.
Kontrolka ta otrzymała Symbol „Input1” oraz została osadzona w każdym z wariantów i będzie zawsze posiadać ten Symbol. Następnie wchodząc w ustawienia wielojęzyczności i określając język oraz tekst, parametry te zostaną automatycznie przeniesione na pozostałe dwa warianty widoków. Takie rozwiązanie znacząco przyspiesza i ułatwia pracę developera – nie musi on bowiem wykonywać tej samej pracy trzykrotnie.
Uwaga! Wielojęzyczność odkłada się na każdym wariancie widoku bez względu na to, czy na moment jej określenia inne kłódki (względem widoku na którym pracujemy) były zamknięte. Nadrzędną kwestią jest tutaj zgodność Symbolu danej kontrolki między widokami. Jeżeli chcemy, aby Użytkownik widział różne wartości, musimy położyć odrębne wobec siebie kontrolki (widok desktop kontrolka z Symbolem Input1, widok tablet Input2, widok mobile Input3 itd.). Ważnym jest, aby Symbole te były unikalne nie tylko w ramach konkretnego widoku, ale i całego Ekranu.
Jak konfigurować słowniki i walidacje?
Prace translatorskie mogą zakładać również konieczność konfiguracji słowników. W przypadku słowników statycznych, to jest utworzonych bezpośrednio w Architekcie Ferryt 2.0, działanie jest identyczne, jak dla konfiguracji kontrolek na Ekranach (zaznaczone na czerwono):

i kolejno:

Użycie słowników dynamicznych, opartych o procedury i tabele w SQL wymaga ciut więcej pracy.
Najpierw musimy określić źródło informacji, z którego nasz słownik dynamiczny będzie czerpać odpowiednie wartości. Zaleca się, aby każdy kontekst językowy przybrał formę osobnej kolumny.
Przykład:

Mamy tutaj wspólny kod (Code) oraz jego wartości słownikowe (NamePL, NameEN, NameDE).
Następnie, do tak stworzonej tabeli odwołujemy się poprzez procedurę składowaną:
CREATE PROCEDURE [dbo].[sp_MultiLanguageTestDictionary]
(
@parentSymbol NVARCHAR(MAX),
@applicationGuid NVARCHAR(MAX),
@cultureInfo NVARCHAR(10) -- 'pl-PL', 'en-GB', 'de-DE'
)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @ElementNameColumn NVARCHAR(50);
-- Wybór kolumny Name w zależności od cultureInfo
IF @cultureInfo = 'pl-PL'
SET @ElementNameColumn = 'ElementNamePL';
ELSE IF @cultureInfo = 'en-GB'
SET @ElementNameColumn = 'ElementNameEN';
ELSE IF @cultureInfo = 'de-DE'
SET @ElementNameColumn = 'ElementNameDE';
ELSE
SET @ElementNameColumn = 'ElementNamePL'; -- Domyślnie PL (zabezpieczenie)
DECLARE @sql NVARCHAR(MAX);
-- Klucz zawsze ten sam, Name dynamicznie w zależności od cultureInfo
SET @sql = '
SELECT
ElementCode AS [Key],
' + QUOTENAME(@ElementNameColumn) + ' AS [Name]
FROM [dbo].[Test_MultiLanguage] WITH (NOLOCK)
';
EXEC sp_executesql @sql;
END;
GO
W oparciu o powyższe, możemy stworzyć teraz słownik dynamiczny w Architekcie Ferryt 2.0.
W przypadku walidacji, wielojęzyczność możemy konfigurować między innymi dla wyrażeń regularnych (regex) oraz skryptów. Komunikaty regexów określamy identycznie, jak dla przytoczonych wcześniej kontrolek na Ekranach lub słowników statycznych (zaznaczone na czerwono):


Jeżeli w trakcie konfiguracji pominiemy któryś z języków, na formularzu zaprezentowany będzie komunikat w języku polskim (a dokładniej, to zgodnie ze wspomnianym wcześniej parametrem System.DefaultCulture (domyślnie „pl-PL”)).
Dla walidacji tworzonej jako skrypt, treści komunikatów musimy określić bezpośrednio w nim:

„SetTextML” rozumiane jest tutaj jako „ustaw tekst wielojęzyczności [multi-language]”.
Uwaga! Dla walidacji skryptowej, odmiennie od poprzednich przypadków, brak określenia komunikatu walidacyjnego dla konkretnego języka nie będzie skutkować informacją w języku polskim, nawet jeśli została ona określona bezpośrednio w tym skrypcie.
W tym przypadku wyświetlony zostanie Komunikat (zaznaczone na czerwono):

Dopiero teraz w przypadku braku jego określenia (dla języków innych niż polski) system zachowa się tak samo jak wcześniej:

Przykład:
Formularz procesowany jest w kontekście językowym „EN”, uruchomiona została walidacja skryptowa,
nie posiada ona zdefiniowanego validation.SetTextML(„en-GB”,”validation text here”); walidacja nie posiada również określonego Komunikatu dla języka angielskiego. Dopiero teraz system zaprezentuje „Błędna wartość” w języku polskim (domyślnym).
Podsumowanie
Podsumowując, platforma low-code Ferryt 2.0 obsługuje warianty wielojęzyczne oraz wspiera użytkowników w ich szybkim tworzeniu i konfiguracji. Rozbudowane narzędzia pozwalają na development treści wielojęzycznej rozumianej jako flow procesu, ekrany, komunikaty, walidacje i skrypty. Wygodne równoległe działanie między widokami desktop/tablet/mobile znacząco przyspiesza prace translatorskie a wbudowane w platformę zabezpieczenia gwarantują drożność procesu również w przypadku, gdy użytkownik zapomniał nadać treść komunikatowi w języku innym niż domyślny. Wygoda i szybkość konfiguracji a także bezpieczeństwo procesów to niewątpliwe atuty platformy Ferryt 2.0.
1 komentarz
marta.wegrzyn
Dla mnie możliwości, jakie oferuje Ferryt w zakresie tworzenia wersji wielojęzykowych, są wyjątkowo intuicyjne i sprawne w codziennym wykorzystaniu.