Tabele tłumaczeń do lokalizacji gier, sprawdzane, zanim trafią do gry.

Jeden wiersz na klucz, z kontekstem i maksymalną długością dla tłumaczy, i jedna kolumna na język. Każde tłumaczenie ma swój stan, teksty za długie lub gubiące zmienną są oznaczane już podczas pisania, a tabela eksportuje się do CSV, JSON, .po i XLIFF dla Unity, Unreal i Godot.

Zacznij za darmo Otwórz tabelę tłumaczeń

Saltmarrow to przykładowy projekt: jego studio, zespół i gra są fikcyjne.

Tabela tłumaczeń żyje w projekcie

Zamień dowolny arkusz w tabelę tłumaczeń albo zacznij od gotowej. Nodary odczytuje role kolumn z nagłówków, takich jak Key, Context, Max length, English, albo z kluczy w stylu Godota: keys, en, fr, i dodaje język jako nową kolumnę jednym kliknięciem. Tabela jest dokumentem na tej samej mapie co dialogi, postacie i systemy, z których pochodzą jej teksty, i łączy się z nimi jak każdy inny dokument.

Wpisz / i wybierz Tabela tłumaczeń albo zamień w nią istniejący arkusz
Role kolumn odgadywane z nagłówków, a potem sprawdzane przez Ciebie
Współedycja komórka po komórce: dwie osoby sprawdzające różne komórki nigdy się nie nadpisują
Języki pisane od prawej do lewej, jak arabski i hebrajski, wpisywane od prawej do lewej

Czego nie robi Kwestie dialogowe nie trafiają do tabeli same: klucze się wpisuje, wkleja, importuje z arkusza lub dodaje je agent. Tabela mieści do 50 000 komórek, więc duża gra dzieli teksty na kilka tabel.

Projekt Saltmarrow na mapie konstelacji Nodary: dokumenty zgrupowane wokół węzłów Wizja, Świat i fabuła, Postacie, Systemy, Produkcja, Lokalizacja, Audio i Kierunek artystyczny, połączone liniami hierarchii, z kursorami dwóch członków zespołu i listą osób obecnych na żywo. — Tabela tłumaczeń leży pod węzłem Lokalizacja, jedno powiązanie od dokumentów, z których pochodzą jej teksty.

Każde tłumaczenie ma stan i kontrolę

Tłumaczenie ma stan: brak, szkic, sprawdzone, ostateczne albo źródło zmienione, gdy tekst źródłowy zmieni się po jego napisaniu. Nic nie jest przepisywane, gdy zmienia się źródło: każde tłumaczenie pamięta tekst, dla którego powstało. Podczas pisania Nodary oznacza tekst dłuższy niż jego limit w znakach widocznych dla gracza, zgubioną lub dodaną zmienną, tekst pozostawiony w języku źródłowym i zbędne spacje na początku lub końcu.

Postęp każdego języka, z filtrem na to, co wymaga pracy lub ma problemy
Panel tłumacza: źródło, kontekst, liczba znaków i zmienne do zachowania
Oznacz zaznaczenie jako sprawdzone lub ostateczne albo zachowaj stany po drobnej zmianie źródła
Zmienne rozpoznawane w formatach ICU, i18next, Unity, Unreal i printf oraz znaczniki

Czego nie robi Nie ma pamięci tłumaczeniowej, bazy terminologicznej ani wbudowanego tłumaczenia maszynowego. Tłumaczenia pochodzą od Twoich tłumaczy albo od agenta AI, którego o nie poprosisz, a praca agenta trafia do tabeli jako szkice.

Kontekst: Banner when a storm forms. {seconds} counts down
Źródło (Angielski): Storm in {seconds} s. Get to the stilts.Zachowaj {seconds}

Niemiecki (de)

38 z 44 znaków

Zmienne: brak {seconds}

Pseudolokalizacja (do testu interfejsu)[Šţóŕɱ íñ {seconds} š. Ĝéţ ţó ţĥé šţíĺţš. ~~~~~~~~~~~~]

Pliki dla silników i tłumaczy oraz kanał dla Twojego buildu

Eksportuj CSV ze wszystkimi językami dla Godota i Unity, JSON dla i18next i silników, gettext .po z kluczem jako kontekstem dla Unreala i Godota oraz XLIFF 1.2 dla narzędzi tłumaczeniowych, który przenosi stan, limit i kontekst każdego tekstu. Język pseudolokalizowany pokazuje nieprzetłumaczony lub ucięty tekst w Twoim interfejsie, zanim powstanie jakiekolwiek tłumaczenie. A gdy build nie powinien na nikogo czekać, sam pobiera tabelę ze stałego adresu za pomocą klucza danych tylko do odczytu.

Import XLIFF 1.2 lub 2.0, .po, JSON lub CSV, dopasowany po kluczu, z podglądem
Puste tłumaczenie w pliku nigdy nie kasuje tłumaczenia w tabeli
Jeden język jako JSON, .po lub XLIFF albo wszystkie jako CSV; final=1 zostawia tylko teksty ostateczne
Niezmieniona tabela odpowiada 304, do 120 żądań na minutę na klucz

Czego nie robi Formy liczby mnogiej zapisuje się jako komunikaty ICU w jednej komórce: wpisy liczby mnogiej z pliku .po są przy imporcie pomijane. Kanał tylko czyta; nic nie jest przez niego zapisywane z powrotem do Nodary.

Tabela tłumaczeń Saltmarrow w Nodary z otwartym menu eksportu: CSV dla Godota i Unity ze wszystkimi językami, CSV z językiem pseudolokalizacji, a dla wybranego języka JSON dla i18next i silników, gettext .po oraz XLIFF 1.2. — Wszystkie formaty są w menu eksportu tabeli. Kanał danych na tym samym pasku udostępnia tabelę buildowi pod jej adresem.

Agenci wypełniają tabelę bez jej przepisywania

Podłączony przez MCP agent czyta tabelę za pomocą get_localization: postęp każdego języka i teksty, które wciąż wymagają pracy, z ich kontekstem, limitem i problemami. set_translations zapisuje po kluczu, jako szkice, chyba że poprosisz o zatwierdzenie, dodaje klucze lub kolumnę języka i zgłasza, które teksty wyszły za długie lub zgubiły zmienną. Osoby edytujące tabelę w tym samym czasie zachowują swoje komórki.

Podłącz agenta

PytaszUzupełnij jako szkice brakujące niemieckie teksty w tabeli tłumaczeń Saltmarrow. Zachowaj każdą zmienną, zmieść się w każdym limicie długości i powiedz mi, które wciąż mają problem.

Wywoływane narzędzia

search_documents
get_localization
set_translations

Pytania

Jak wyeksportować teksty gry do Unity, Unreal lub Godot?

Otwórz menu Eksportuj w tabeli tłumaczeń. CSV zawiera wszystkie języki, kolumnę kluczy, a potem kolumnę na każdy język, tak jak czytają go Godot i Unity; gettext .po zawiera jeden język z kluczem jako kontekstem, dla Unreala i Godota; JSON daje jeden język jako płaski plik klucz-tekst dla i18next i silników. Sam import odbywa się w Twoim silniku, jego własnymi narzędziami do lokalizacji.

Czy Nodary tłumaczy teksty za mnie?

Nie. Nie ma wbudowanej pamięci tłumaczeniowej ani usługi tłumaczenia maszynowego. Twoi tłumacze pracują w tabeli albo we własnym narzędziu przez XLIFF, a podłączony agent AI też może pisać tłumaczenia, które trafiają jako szkice do sprawdzenia przez człowieka.

Co dzieje się z tłumaczeniem, gdy zmienia się tekst źródłowy?

Każde tłumaczenie przechowuje odcisk źródła, dla którego zostało napisane. Gdy źródło się zmienia, jego tłumaczenia dostają stan Źródło zmienione i nic nie jest przepisywane. Jeśli zmiana była drobna, akcja Drobna zmiana źródła zachowuje ich dotychczasowe stany.

Czy nasz build może pobierać teksty automatycznie?

Tak. Każdy członek może utworzyć w swoim profilu klucz danych tylko do odczytu, dla całej przestrzeni roboczej lub jednego projektu, a przycisk Kanał danych w tabeli podaje jej adresy. Build pobiera jeden język jako JSON, .po lub XLIFF albo wszystkie języki jako CSV, a final=1 pomija wszystko, co nie jest jeszcze ostateczne.

Jakie zmienne i znaczniki rozpoznaje kontrola?

Komunikaty ICU, w tym plural i select, {name} i {0} w zapisie Unity i Unreala, {{name}} z i18next, formy printf, takie jak %s, %d i %1$s, oraz znaczniki, takie jak <b> czy <color=#f00>. Długość liczy znaki, które widzi gracz: litera z akcentem lub emoji liczy się raz, a znaczniki się nie liczą.

Czy tłumacze mogą odesłać swoje pliki?

Tak. Importuj XLIFF 1.2 lub 2.0, gettext .po, JSON lub CSV, do 8 MB. Tłumaczenia są dopasowywane po kluczu, klucze, których tabela nie ma, są wypisywane, a nie dodawane, podgląd pokazuje każdą zmianę przed jej zastosowaniem, a tłumaczenie zrobione ze starszego źródła trafia do tabeli ze stanem Źródło zmienione.

Postaw swoje teksty obok swojej gry.

Zacznij za darmo, wpisz / i wybierz Tabela tłumaczeń, a potem wklej pierwsze klucze. Bez karty, bez instalacji.