Lokalizace III: Dokončení a soubory .nib - MujMAC.cz - Apple, Mac OS X, Apple iPod

Odběr fotomagazínu

Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!

 

Zadejte Vaši e-mailovou adresu:

Kamarád fotí rád?

Přihlas ho k odběru fotomagazínu!

 

Zadejte e-mailovou adresu kamaráda:

Seriály

Více seriálů



Začínáme s

Lokalizace III: Dokončení a soubory .nib

24. srpna 2004, 00.00 | Pokud jste četli předchozí díl, možná si ještě pamatujete na otázku, kterou jsem na jeho konci položil: zda se výrazněji liší velikost výchozího (složka _NewBase) a lokalizovaného (složka _NewLoc) balíku aplikace, a pokud ano, tak proč. Pokud už máte odpověď na její první triviální část (zda), zkuste si promyslet i tu druhou (proč).

Úkol z minula

Pokud jste četli předchozí díl, možná si ještě pamatujete na otázku, kterou jsem na jeho konci položil: zda se výrazněji liší velikost výchozího (složka _NewBase) a lokalizovaného (složka _NewLoc) balíku aplikace, a pokud ano, tak proč. Pokud už máte odpověď na její první triviální část (zda), zkuste si promyslet i tu druhou (proč). Měli byste dojít k následujícímu:

  • Pokud jste experimentovali s aplikací z českého lokalizovaného systému a lokalizovali jí z angličtiny do češtiny (nastavili jste tak na začátku „Target and Base Locale“), byla výsledkem aplikace, která obsahovala původní anglickou a vaší českou lokalizaci (tedy odpovídající podadresáře .lproj). Velikost byla tedy přibližně stejná.
  • Byla-li základem aplikace z mezinárodního systému, nebo z českého lokalizovaného systému, ale lokalizovali jste ji z angličtiny například do slovenštiny, byla výsledkem aplikace s původní anglickou nebo i českou lokalizací a obsahující navíc vaší lokalizaci slovenskou. Aplikace tedy přibrala pár kilo.

Toto chování vyplývá z filosofie balíků (bundles), o které jsme mluvili v prvním díle. Pokud byste trochu předběhli a zkusili lokalizovat starší aplikaci, která sestává z jediného souboru, byla by původní lokalizace nahrazena tou vaší. V Mac OS X byste ale takovou aplikaci hledali marně. Připomínám tedy, že u aplikací ve formě balíků se výběr lokalizace prezentované uživateli řídí jeho jazykovými předvolbami. Případně lze jazyky deaktivovat přímo pro daný balík prostřednictvím jeho informačního okna (dojde tím k přesunu daného adresáře .lproj do podadresáře Resources Disabled).

Teď už ale dost opakování – vrhneme se do dokončování naší pokusné lokalizace.


Dokončení v AppleGlotu

V posledním díle jsme si ukázali, jak pomocí příkazu Incremental Pass můžeme postupně dotvářet lokalizaci aplikace až k úplnému přeložení textů, které nám AppleGlot z balíku vytáhl. Pokud jsme již s výsledky této fáze spokojení, je třeba konečný produkt zbavit dočasných souborů, které AppleGlot do balíku pro své potřeby umístil. Toho dosáhneme pomocí příkazu Final Pass z nabídky Actions.


Překlad zbylých souborů

V ideálním případě bychom nyní byli s prací hotovi, ve skutečnosti nás ale velký díl ještě čeká. Než se ponoříme do útrob balíku a budeme v něm pátrat po nedodělcích, vytvoříme si raději jeho záložní kopii (tedy kopii finalizované aplikace ve složce _NewLoc).

Zvlášť pokud jste první kdo aplikaci lokalizuje, je třeba se přesvědčit, že soubory, které jsou přímo v adresáři Resources (tedy ty, které jsou společné pro všechna národní prostředí) jsou skutečně nezávislé na lokalizaci. V opačném případě je nejlepší se obrátit na autora aplikace. Rychle lze problém vyřešit vytvořením lokalizované verze v lokalizovaném adresáři .lproj (originál ponecháme, kde je). Aplikace totiž nejdříve hledá v adresáři .lproj aktivní lokalizace pak teprve přejde o úroveň výš.

Dál už budeme pracovat pouze s obsahem našeho adresáře .lproj. Bude třeba v něm lokalizovat všechny soubory vyjma těch s příponami .nib, .strings a .rsrc, které jsme zpracovali pomocí AppleGlotu.


texty – .txt, .rtf, .rtfd, .html

V případě souborů s příponou .txt (nebo bez přípony) je v prvé řadě třeba zachovat kódování textu. Obvykle platí, že texty jsou v kódování UTF-8 nebo UTF-16, zřídka i ve starém kódování Mac OS (Roman, Central European a další). Pokud k úpravám používáte TextEdit, nespoléhejte na to, že kódování rozezná a soubor uloží v tomtéž. Velmi dobře nám pomůže nástroj file pro příkazovou řádku. Stačí napsat do okna aplikace Terminál (v Obslužných programech, resp. Utilities) „file “ (bez uvozovek s mezerou na konci), do okna vhodit inkriminovaný soubor a odřádkovat. Pokud je identifikováno UTF-8 ani UTF-16, zachováme toto kódování. Pokud je identifikováno ASCII, neobsahuje text žádné kódované znaky, nejlepší je předpokládat, že je tedy v UTF-8 (rozhodně ale ne UTF-16). Pokud file kódování neidentifikuje, použijeme Mac OS Central European. Kódováni lze v TextEditu zvolit v dialozích pro ukládání a otevírání.

V případě souborů .rtf a .rtfd je jen vhodné dodržet jejich typ. Soubory .rtfd obvykle obsahují obrázky, pokud je soubor .rtfd bez obrázků, neměli bychom jeho příponu měnit.

Soubory .html obvykle obsahují nápovědu. Pro jejich editaci můžeme použít AD Viewer, který zvýrazní syntaxi (nám stačí měnit pouze text, tagy tvořící strukturu dokumentu naopak můžeme ponechat).


obrázky – .tiff, .jpeg, .png .gif, …

Měli bychom zachovat všechny parametry: formát (tedy i příponu), barevnou hloubku, velikost, případný alfa kanál. Pokud potřebujeme velikost obrázku změnit, bude možná potřeba upravit jeho zobrazení v souboru .nib (k tomu se dostaneme později), případně, pokud si nejsme jisti, že to stačí, kontaktovat autora, aby upravil odpovídajícím způsobem program.


seznamy vlastností (property lists) – .plist

Jde o XML soubory, které lze poměrně dobře upravovat pomocí AD Vieweru, který jednak rozpozná jejich kódování (vždy UTF-8), jednak zvýrazní syntaxi. Překládáme obvykle pouze řetězce ohraničené <string> a </string>, pomocí řetězců uvnitř <key> totiž program obvykle položky vyhledává, překládáme je tedy pouze pokud můžeme ověřit, že to nezmění chování programu.


Úpravy grafického rozhraní v Interface Builderu

Protože některé překlady mohou mít jinou délku než původní texty, je třeba podle toho upravit velikosti a rozmístění prvků grafického rozhraní aplikace. Nejdříve se budeme věnovat souborům .nib, které jsou používány moderním softwarem a jdou velmi pohodlně upravovat pomocí Interface Builderu.

Na následujícím obrázku vidíte hlavní okno (vlevo dole), ve kterém nás zajímá záložka Instances (instance tříd, tedy objekty GUI). Položky s ikonou modré kostky nebo jedničky nás nezajímají. Dál se tu objeví nabídky, ty také upravovat nemusíme, jejich velikost se určuje automaticky. Zbývají tedy okna a někdy views, které si můžeme představit jako jakési výseky rozhraní nebo obsahy oken. Po poklepání na ikonu objektu se otevře jeho okno (na obrázku vlevo nahoře). Samotné okno nebo view obsahuje další objekty, prvky rozhraní: tlačítka, rámečky, pole a další. Všechny texty by měly být lokalizované, jediné, co tedy budeme upravovat je poloha a velikost. Nelze například smazat některý z objektů a nahradit ho novým, byť téže třídy!

prostredi Interface Builderu

Práce je podobná jako v grafickém editoru, s umístěním i rozměry se manipuluje tažením, velikost okna lze měnit, jak jsme zvyklí. Interface Builder se nám pomocí modrých vodítek bude snažit vnutit standardní rozestupy mezi některými prvky, pokud je ovšem původní rozvržení záměrně nedodržuje můžeme tuto funkci vypnout vybráním Layout > Guides > Disable Aqua Guidelines. Naopak nám při zachování původního rozvržení pomůže klávesa alt, díky které se zobrazí vzdálenosti mezi označeným objektem a objekty, přes které přejíždíme kurzorem (viz obrázek), zároveň přitom můžeme přemisťovat objekt kurzorovými klávesami. Klávesovou zkratkou command-shift-I si můžeme vyvolat okno inspektoru (na obrázku vpravo), které zobrazuje atributy právě označeného objektu, jediné které nás zajímají, jsou v oddílu Size.

Po upravení velikosti a polohy všech objektů grafického rozhraní, u kterých to bylo třeba, práci uložíme a pokud jsme si jistí, že jsme neudělali při úpravách žádné chyby, smažeme záložní soubor, který Interface Builder vytvořil, má stejné jméno, jen doplněné vlnovkou. V dokončené lokalizaci by jen zabíral místo.


Jak dál

Pro kakaové aplikace, které neobsahují soubory .rsrc vám budou stačit to, co jste se naučili v dosavadních třech dílech. Příště se budeme věnovat především karbonovým aplikacím a jejich prostředkům (resources), proto už teď uvedu několik odkazů, které stojí za návštěvu, a několik nástrojů, které by vám mohly pomoci, až se pustíte do skutečné lokalizace:

Dokumentaci včetně HIG naleznete také offline v aplikaci Xcode: Help > Show Documentation Window.

  • FileMerge (součást Xcode Tools) umí přehledně porovnat, případně sloučit, dva soubory nebo celé adresářové stromy. Její pomoc oceníte, až se budete ztrácet v různých verzích a úpravách nebo, až budete spolupracovat s dalšími lidmi. Jejím ekvivalentem pro příkazovou řádku je diff.
  • PackageMaker (součást Xcode Tools) vám pomůže s vytvářením instalačních balíků.
  • HexEdit je docela povedený šestnáctkový editor, pomocí kterého můžete prohlížet, upravovat a porovnávat libovolné soubory.
  • Polyglot pomůže s hledáním chyb a nedodělků v lokalizaci.

Obsah seriálu (více o seriálu):

Tématické zařazení:

 » Rubriky  » Informace  

 » Rubriky  » Agregator  

 » Rubriky  » Začínáme s  

 

 

 

Nejčtenější články
Nejlépe hodnocené články
Apple kurzy

 

Přihlášení k mému účtu

Uživatelské jméno:

Heslo: