Tłumaczenia
Tłumaczenia, terminologię i poprawność językową dostarcza oraz zatwierdza klient, agencja albo wskazany lingwista.
Web
Techniczna lokalizacja stron i aplikacji internetowych
Integruję dostarczone tłumaczenia z istniejącą stroną lub aplikacją, aby wersje językowe działały poprawnie w treściach, kodzie, routingu, formularzach i SEO.
- gotowe tłumaczenia
- routing oraz fallback
- metadata i hreflang
- techniczne QA wersji językowych
Granica odpowiedzialności
Lokalizacja techniczna integruje tłumaczenie, ale nie zastępuje jego kontroli językowej.
Integracja techniczna
Zakres obejmuje wydzielenie i integrację treści, routing, układ, metadata, formularze i techniczne zachowanie wersji językowych w uzgodnionym zakresie.
QA techniczne
QA techniczny sprawdza działanie i prezentację wersji językowej; nie zastępuje korekty, redakcji ani akceptacji tłumaczenia.
Środowiska
- statyczny HTML
- Next.js
- React
- JSON
- WordPress
- inne CMS-y
- aplikacje internetowe
- treści z bazy danych
Treść i interfejs
- wydzielenie tekstu z kodu
- pliki tłumaczeniowe
- integracja tłumaczeń
- przełącznik języka
- grafiki z tekstem
- formularze i błędy
i18n i SEO
- routing językowy
- hreflang
- metadata
- Open Graph
- schema.org
- canonicale
- wersje regionalne
Jakość prezentacji
- długość tekstu i przepełnienia
- fonty
- RTL
- daty, liczby i waluty
- test responsywności
- techniczne SEO
Architektura i18n porządkuje treść, routing oraz zachowanie wersji językowych.
Centralizacja treści i klucze tłumaczeniowe pomagają uniknąć sytuacji, w której ten sam tekst jest zapisany w wielu komponentach, plikach lub rekordach danych. Model obejmuje również fallback, język domyślny i sposób obsługi brakujących wartości.
Routing, indeksacja, canonicale, hreflang i wersje regionalne projektuję zgodnie z architekturą istniejącego projektu. Nie deklaruję jednej konkretnej biblioteki, ponieważ właściwe rozwiązanie zależy od użytego frameworka, CMS-u i danych.
- centralizacja treści
- klucze tłumaczeniowe
- fallback
- routing i język domyślny
- indeksacja i canonicale
- wersje regionalne
CMS, API i baza danych wymagają analizy konkretnego dostępu oraz modelu treści.
Dla statycznego HTML, Next.js, React, WordPressa, innych CMS-ów, aplikacji i treści z bazy danych proces może wyglądać inaczej. Zakres zależy od struktury treści, dostępnych API, pluginów, uprawnień i możliwości bezpiecznej pracy na środowisku staging.
Przed zmianami ustalam, czy można wykonać kopię zapasową oraz jakie środowisko jest dostępne do próby. Nie zakładam, że każdy CMS lub plugin umożliwia ten sam model plików językowych, routingu czy publikacji.
- dostęp i uprawnienia
- struktura treści
- pluginy i API
- środowisko staging
- możliwość wykonania kopii zapasowej
- ograniczenia systemu
Proces technicznej lokalizacji
Od audytu technologii do publikacji wersji językowej z kontrolą techniczną.
01
Audyt technologii
- Materiał wejściowy
- Kod, CMS, aplikacja, API, baza danych oraz informacje o hostingu i środowiskach.
- Działanie
- Sprawdzam architekturę, dostęp, uprawnienia, pluginy i możliwości pracy na kopii albo stagingu.
- Decyzja klienta
- Potwierdza dostępne środowisko oraz właściciela konfiguracji.
- Rezultat etapu
- Lista ograniczeń i plan analizy.
- Ryzyko do rozstrzygnięcia
- Brak dostępu lub kopii zapasowej może ograniczyć zakres zmian.
02
Inwentaryzacja treści
- Materiał wejściowy
- Strony, komponenty, dane, grafiki, formularze, komunikaty błędów i metadata.
- Działanie
- Wskazuję teksty w kodzie, CMS-ie, JSON-ie, bazie danych i zasobach graficznych.
- Decyzja klienta
- Potwierdza komplet tłumaczeń oraz osobę zatwierdzającą język.
- Rezultat etapu
- Mapa treści do lokalizacji.
- Ryzyko do rozstrzygnięcia
- Tekst ukryty w grafice lub logice aplikacji może wymagać osobnej decyzji.
03
Model lokalizacji
- Materiał wejściowy
- Mapa treści, tłumaczenia i wymagania rynków.
- Działanie
- Projektuję klucze, fallback, język domyślny, routing, przełącznik i wersje regionalne zgodnie z architekturą projektu.
- Decyzja klienta
- Akceptuje model URL, języka domyślnego i zachowania braków.
- Rezultat etapu
- Uzgodniona architektura i18n.
- Ryzyko do rozstrzygnięcia
- Zmiana modelu po integracji może wymagać migracji danych lub URL.
04
Próbna wersja
- Materiał wejściowy
- Reprezentatywne ekrany, tłumaczenia i najtrudniejsze elementy interfejsu.
- Działanie
- Integruję próbkę, sprawdzam długość tekstu, fonty, responsywność, formularze i RTL, gdy występuje.
- Decyzja klienta
- Ocena układu i decyzja dla miejsc wymagających adaptacji.
- Rezultat etapu
- Zweryfikowany wzorzec wersji językowej.
- Ryzyko do rozstrzygnięcia
- Dłuższy tekst lub inny alfabet może ujawnić potrzebę zmiany komponentu.
05
Integracja
- Materiał wejściowy
- Zatwierdzony model i tłumaczenia.
- Działanie
- Wprowadzam pliki lub dane językowe, routing, przełącznik, treści, grafiki, daty, liczby, waluty i formularze w uzgodnionym zakresie.
- Decyzja klienta
- Potwierdza gotowość tłumaczeń oraz kolejność publikacji rynków.
- Rezultat etapu
- Zintegrowane wersje językowe.
- Ryzyko do rozstrzygnięcia
- Brakujące klucze i niespójne dane wymagają decyzji przed publikacją.
06
Techniczne SEO
- Materiał wejściowy
- Wersje językowe i model URL.
- Działanie
- Konfiguruję lub sprawdzam metadata, Open Graph, schema.org, canonicale, hreflang i indeksację wersji językowych.
- Decyzja klienta
- Akceptuje rynki, warianty regionalne i politykę indeksacji.
- Rezultat etapu
- SEO techniczne wersji językowych.
- Ryzyko do rozstrzygnięcia
- Decyzje o indeksacji zależą od kompletności i gotowości treści.
07
Test
- Materiał wejściowy
- Zintegrowane środowisko i lista kryteriów QA.
- Działanie
- Kontroluję klucze, fallback, przepełnienia, formularze, metadata, routing, mobilność, grafiki, kodowanie, fonty i RTL.
- Decyzja klienta
- Akceptuje wyniki testów oraz ograniczenia środowiska.
- Rezultat etapu
- Raport technicznego QA.
- Ryzyko do rozstrzygnięcia
- QA techniczny nie potwierdza poprawności językowej tłumaczenia.
08
Publikacja
- Materiał wejściowy
- Zweryfikowane wersje i uzgodnione środowisko produkcyjne.
- Działanie
- Przygotowuję wdrożenie oraz kontrolę podstawowych elementów po publikacji w uzgodnionym zakresie.
- Decyzja klienta
- Zatwierdza moment publikacji i dostęp do środowiska.
- Rezultat etapu
- Opublikowane wersje językowe lub plan ich uruchomienia.
- Ryzyko do rozstrzygnięcia
- Zmiany hostingu, CMS-u lub danych produkcyjnych wymagają właściwych uprawnień.
Powiązane usługi
Techniczna lokalizacja WWW łączy się z tworzeniem stron, lokalizacją dokumentów i dostępnością.
Strony internetowe
Projektuję, tworzę i modernizuję strony internetowe bez e-commerce: architektura, kod, techniczne SEO, dostępność, wdrożenie i opieka.
Lokalizacja dokumentów
Przygotowuję wersje językowe raportów, prezentacji, publikacji i materiałów do druku lub publikacji cyfrowej.
Dostępność WCAG
Techniczna kontrola i remediacja materiałów cyfrowych w uzgodnionym zakresie: struktura, kolejność czytania, kontrast, teksty alternatywne i eksport.
Odpowiedzi
Najczęstsze pytania
Odpowiedzi rozdzielają tłumaczenie, integrację techniczną, CMS, SEO i publikację wersji językowej.
Tłumaczenie tworzy treść w innym języku, a lokalizacja techniczna integruje tę treść ze stroną, aplikacją, routingiem, metadata, formularzami i układem. Gotowe tłumaczenie może nadal powodować przepełnienia, błędy w nawigacji albo problemy SEO. Poprawność językową zatwierdza klient, agencja albo lingwista.
Zakres może wymagać repozytorium, kodu, dostępu do CMS, eksportu treści, plików JSON, API, bazy danych albo środowiska staging. Potrzebne są też gotowe tłumaczenia, instrukcje językowe, lista języków i wymagania rynków. Bez dostępu do źródła część pracy może ograniczyć się do rekomendacji.
Nie. Statyczny HTML, Next.js, React, WordPress, inne CMS-y i aplikacje z bazą danych mają różne modele treści, routingu i publikacji. Zakres zależy od uprawnień, struktury danych, pluginów, API i możliwości wykonania kopii zapasowej. Dlatego najpierw potrzebny jest audyt technologii.
Tłumaczenia, terminologię i kontrolę językową dostarcza oraz zatwierdza klient, agencja albo wskazany lingwista. Techniczny QA sprawdza integrację, routing, układ, formularze i metadata, ale nie zastępuje korekty językowej. Jeśli tekst wymaga skrócenia, decyzję językową podejmuje właściwa osoba.
Może obejmować adresy URL, język domyślny, canonicale, hreflang, metadata, Open Graph, schema.org, indeksację i mapę wersji regionalnych. Nie każdy projekt potrzebuje tego samego zestawu elementów. Wdrożenie zależy od architektury strony i sposobu publikacji treści.
Formularze, walidacje, komunikaty systemowe, przyciski i błędy często są zapisane w innych miejscach niż zwykła treść strony. Grafiki z tekstem wymagają źródeł albo osobnej decyzji o odtworzeniu. Te elementy trzeba uwzględnić w inwentaryzacji, żeby wersja językowa była kompletna.
Po integracji trzeba sprawdzić przepełnienia, łamanie, fonty, mobilność, daty, liczby, waluty i zachowanie interfejsu. RTL wymaga oceny kierunku tekstu, układu i właściwego lingwisty. Test techniczny nie zatwierdza poprawności językowej.
Publikacja może być częścią zakresu, jeżeli są dostępne uprawnienia, staging, kopia zapasowa i ustalony proces wdrożenia. W innym przypadku mogę przygotować zmiany, instrukcję lub paczkę do wdrożenia przez zespół klienta. Nie zakładam jednego procesu dla każdego CMS-u ani aplikacji.
Opisz technologię, treści i planowane wersje językowe
Podaj środowisko, dostępne tłumaczenia, rynki, źródła treści, CMS lub aplikację, wymagania SEO oraz informacje o stagingu i kopii zapasowej.