Dobra praktyka

DLA STRONY INTERNETOWEJ

Użycie wzorców Markdown poprawia czytelność i ułatwia konserwację, zarówno dla tłumacza, jak i dla skryptów Twojej witryny, które będą z nich pobierać treść.
W przypadku nazwanych kotwic na wielojęzycznej stronie internetowej, interesującym podejściem jest „na stałe zakodowanie” (hardcoding) linków z wykorzystaniem formatowania Markdown.
Np.
dla znacznika <h2/> z kotwicą

etykieta-w-bieżącym-języku

LLM-y są bardziej efektywne niż ludzie w ochronie linków, a LSDE pozwala wykrywać problemy między różnymi wersjami językowymi.
W ten sposób możesz udostępnić link, który będzie działał we wszystkich językach i używać LSDE do zarządzania zastępowaniem przestarzałej kotwicy.


Niejasność kodu

Unikaj niejasności podczas pracy z modelami zorientowanymi na dane.
Przykład:
Zła praktyka: Termin 'key' nie jest wystarczająco wyraźny i utrudnia jego wyszukiwanie.

ts
const PRODUCTS: Product[] = [
	{
		id: 'fcf7o',
		logo: '/icons/fcf7o-icon-40.webp',
		label: 'FCF7O',
		key: 'game:fcf7o.words.game_title',
	},
	{
		id: 'lsde',
		logo: '/icons/lsde-icon-40.webp',
		label: '<c1>LSDE</c1>',
		key: 'software:lsde.name',
	},
	{
		id: 'lsge',
		logo: '/icons/lsge.webp',
		label: 'LSGE',
		key: 'software:lsge.name',
	},
];


Dobra praktyka: Przyjmij jednolitą i spójną konwencję.
Termin i18nKey jest bardzo wyraźny i umożliwia precyzyjne wyszukiwanie tej wartości za pomocą wyrażeń regularnych (Regex).
ts
const PRODUCTS: Product[] = [
	{
		id: 'fcf7o',
		logo: '/icons/fcf7o-icon-40.webp',
		label: 'FCF7O',
		i18nKey: 'game:fcf7o.words.game_title',
	},
	{
		id: 'lsde',
		logo: '/icons/lsde-icon-40.webp',
		label: '<c1>LSDE</c1>',
		i18nKey: 'software:lsde.name',
	},
	{
		id: 'lsge',
		logo: '/icons/lsge.webp',
		label: 'LSGE',
		i18nKey: 'software:lsge.name',
	},
];




Leniwość

Złe pomysły rodzą się z lenistwa.

Nie próbuj oszczędzać kluczy, wykonując operacje w celu pobrania treści.
Przykład:
javascript
const [title, subtitle] = t( 'game:game.title' ).split( /[:：]/ );

To jest złudnie dobry pomysł, ponieważ w niektórych językach znaki mogą się różnić, a kolejność słów może ulec zmianie.



Format tagów

Zminimalizuj kod przeznaczony do projektowania bezpośrednio w tekście, aby móc nim sterować z poziomu bazy kodu.
Na przykład, możesz wskazać lokalizację obrazu, ale nie jego styl ani sposób renderowania.
Jeśli musisz wprowadzić zmiany w projekcie, nie chcesz być zmuszony do ponownego tłumaczenia tekstu na 10 języków tylko po to, aby zmienić styl tagu!

Tagi mogą zawierać identyfikator, ale dodawanie dodatkowych informacji jest zazwyczaj silnie odradzane i stanowi złą praktykę.
Przykład: Nie rób tak:
<img src='url' left />
ale raczej:
<img id=1 />
Następnie pobierzesz ID tagu obrazu, aby zastosować do niego niezbędne style w bazie kodu.
ID-y powinny być używane dosłownie, a nie za pośrednictwem ich indeksu.
W rzeczywistości, w różnych językach tagi mogą zostać przesunięte i nie odpowiadać już początkowemu indeksowi.
Użycie naturalnych indeksów wprowadza również złożoność dla programisty; próba odgadnięcia, któremu indeksowi odpowiada obraz lub tag, to prawdziwa łamigłówka.
Dlatego używaj tagów z identyfikatorem, jeśli chcesz je personalizować po interpolacji.



CSS

W przypadku tłumaczenia strony internetowej, gdy masz paragrafy, zdecyduj się na minimalną wysokość (`min-height`) po przetłumaczeniu, aby uniknąć wizualnych przesunięć podczas zmian językowych.
Np. `mih={'3lh'}`
Pozwala to na ustawienie minimalnej wysokości opartej na języku, który zajmuje najwięcej linii, zapewniając spójne i stonowane doświadczenie użytkownika (UX).

Przestrzeń nazw


Zawsze dołączaj 'przestrzeń nazw' do swoich kluczy tłumaczeniowych, nawet jeśli masz tylko jedną.
To znacznie ułatwia ustawienie wzorca Regex do odnajdywania Twoich kluczy.
Np. game:a.b.c, common:a.b.c