Internacionalização e localização para sites estáticos

A internacionalização e a localização são mais do que apenas escrever seu conteúdo em vários idiomas. Você precisa de uma estratégia para determinar qual localização enviar e codificar para fazê-lo. Você precisa ser capaz de oferecer suporte não apenas a idiomas diferentes, mas a regiões diferentes com o mesmo idioma. Sua interface do usuário precisa ser responsiva, não apenas ao tamanho da tela, mas a diferentes idiomas e modos de escrita. Seu conteúdo precisa ser estruturado, até a microcópia em sua interface do usuário e o formato de suas datas, para ser adaptável a qualquer idioma que você usar. Fazer tudo isso com um gerador de site estático, como o Eleventy, pode dificultar ainda mais, porque você pode não ter um banco de dados, mas um servidor. Tudo pode ser feito, porém, mas é preciso planejamento.

Ao desenvolver o chromeOS.dev, sabíamos que precisávamos disponibilizá-lo para um público global. Certificar-se de que nossa base de código possa suportar vários locais (idioma, região ou combinação dos dois) sem precisar codificar cada um de forma personalizada, permitindo que a tradução seja feita com o mínimo de conhecimento desse sistema possível, seria fundamental para tornar isso acontecer. Nossos criadores de conteúdo precisavam se concentrar na criação de conteúdo e nossos tradutores na tradução de conteúdo, com o mínimo de trabalho possível para colocar seu trabalho no site e implantado. Acertar esse conjunto de necessidades às vezes conflitantes é o cerne do que é necessário para internacionalizar bases de código e localizar sites.

Internacionalização (i18n) e localização (l10n) são dois lados da mesma moeda. A internacionalização é sobre como, no nosso caso, o software é projetado para que possa ser adaptado para vários idiomas e regiões sem a necessidade de alterações de engenharia. A localização, por outro lado, trata-se de realmente adaptar o software para esses idiomas e regiões. A internacionalização pode acontecer em toda a pilha do site; de HTML, CSS e JS para projetar considerações e construir sistemas. A localização acontece principalmente na criação de conteúdo (tanto cópia em formato longo quanto microcópia) e gerenciamento.

Nota : Para os curiosos, i18n e l10n são tipos de abreviaturas conhecidas como numerônimos. A11y, para acessibilidade, é outro numerônimo comum no desenvolvimento web.

Internacionalização (i18n)

Ao descobrir a internacionalização, geralmente há três itens que você precisa considerar: como descobrir qual idioma e/ou região o usuário deseja, como garantir que ele receba conteúdo em sua localização preferida e como adaptar seu site para se ajustar a essas diferenças. Embora as especificações de implementação possam mudar para sites dinâmicos (que renderizam uma página quando um usuário a solicita) e sites estáticos (onde as páginas são criadas antes de serem implantadas), os conceitos principais devem permanecer os mesmos.

Determinando o idioma e a região do usuário

A primeira coisa a considerar ao descobrir a internacionalização é determinar como você deseja que os usuários acessem o conteúdo localizado. Essa decisão se tornará fundamental para a configuração de outros sistemas, por isso é importante decidir isso com antecedência e garantir que as compensações funcionem bem para seus usuários.

Geralmente, existem três maneiras de alto nível de determinar qual localização servir aos usuários:

1. Localização do endereço IP;
2. Cabeçalho Accept-Language ou navigator.languages ​​;
3. Identificador na URL.

Muitos sistemas acabam combinando um, dois ou todos os três, ao decidir qual localização servir. No entanto, enquanto estávamos investigando, encontramos problemas com o uso de endereços IP e cabeçalhos Accept-Language que consideramos significativos o suficiente para serem removidos de nossa consideração:

• O idioma preferido de um usuário geralmente não se correlaciona com sua localização física, fornecida pelo endereço IP. Só porque alguém está fisicamente localizado nos Estados Unidos, por exemplo, não significa que eles preferem conteúdo em inglês.
• A análise de localização de endereços IP é difícil, geralmente não confiável e pode impedir que o site seja rastreado pelos mecanismos de pesquisa.
• Os cabeçalhos Accept-Language geralmente nunca são definidos explicitamente e fornecem apenas informações sobre o idioma, não a região. Devido às suas limitações, isso pode ser útil para estabelecer uma estimativa inicial sobre o idioma, mas não é necessariamente confiável.

Por esses motivos, decidimos que seria melhor não tentar inferir idioma ou região antes que um usuário chegasse ao nosso site, mas sim ter indicadores fortes em nossos URLs. Ter indicadores fortes também nos permite supor que eles estão obtendo o site no idioma que desejam apenas a partir de seu URL de acesso, fornece uma maneira fácil de compartilhar conteúdo localizado diretamente sem preocupação de redirecionamento e fornece uma maneira limpa de permitir que os usuários mudam seu idioma preferido.

Existem três padrões comuns para criar identificadores em URLs:

1. Fornecer domínios diferentes (geralmente TLDs ou subdomínios para diferentes regiões e idiomas (por exemplo, example.com e example.de , en.example.org e de.example.org );
2. Tenha subdiretórios localizados para conteúdo (por exemplo, example.com/en e example.com/de );
3. Exiba conteúdo localizado com base em parâmetros de URL (por exemplo, example.com?loc=en e example.com?loc=de ).

Embora comumente usados, os parâmetros de URL geralmente não são recomendados porque é difícil para os usuários reconhecerem a localização (junto com vários problemas de análise e gerenciamento). Também decidimos que domínios diferentes não eram uma boa solução para nós; nosso site é um Progressive Web App e cada domínio, incluindo TLDs e subdomínios, é considerado uma origem diferente, exigindo efetivamente um PWA separado para cada localização.

Decidimos usar subdiretórios, o que nos proporcionou um bônus de podermos localizar apenas no idioma ( example.com/en ) ou idioma e região ( example.com/en-US e example.com/en-GB ) conforme necessário enquanto mantendo um único PWA. Também decidimos que cada localização de nosso site ficaria em um subdiretório para que um idioma não fosse elevado acima de outro e que todos os URLs, exceto o subdiretório, seriam idênticos em todas as localizações com base no idioma de criação, permitindo que os usuários alterem facilmente localizações sem precisar traduzir URLs.

Como veicular conteúdo localizado

Depois que uma estratégia para determinar o idioma e a região de um usuário for determinada, você precisará de uma maneira de fornecer a eles o conteúdo certo de maneira confiável. No mínimo, isso exigirá algum tipo de informação armazenada, seja em um cookie, algum armazenamento local ou parte da lógica personalizada do seu aplicativo. Ser capaz de manter as preferências de localização de um usuário é uma parte importante da experiência do usuário i18n; se um usuário identificar que deseja conteúdo em alemão e acessar conteúdo em inglês, você poderá identificar seu idioma preferido e redirecioná-lo adequadamente. Isso pode ser feito no servidor, mas a solução que usamos para o chromeOS.dev é independente de hospedagem e configuração de servidor: usamos service workers. A jornada do usuário é a seguinte:

• Um usuário acessa nosso site pela primeira vez. Nosso service worker não está instalado.
• Qualquer que seja a localização, definimos como seu idioma preferido no IndexedDB. Para isso, presumimos que eles estão chegando lá por algum meio, seja social, de referência ou de pesquisa, que os direcionou com base em outros contextos de localização que não temos. Se um usuário chegar sem um conjunto de localização definido, definimos como inglês, pois esse é o idioma principal do nosso site. Também temos um seletor de idioma em nosso rodapé para permitir que um usuário altere seu idioma. Neste ponto, nosso service worker deve estar instalado.
• Após a instalação do service worker, interceptamos todas as solicitações de URL para navegação no site. Como nossas localizações são baseadas em subdiretórios, podemos identificar prontamente qual localização está sendo solicitada. Uma vez identificada, verificamos se a página solicitada está em um subdiretório localizado, verificamos se o subdiretório localizado está em uma lista de localizações suportadas e verificamos se o subdiretório localizado corresponde às preferências armazenadas no IndexedDB. Se não estiver em um subdiretório localizado ou o subdiretório localizado corresponder às suas preferências, veiculamos a página; caso contrário, fazemos um redirecionamento 302 do nosso service worker para a localização correta.

Agrupamos nossa solução no plugin Workbox, Service Worker Internationalization Redirect. O plug-in, juntamente com seu submódulo de preferências, pode ser combinado para definir e obter a preferência de idioma de um usuário e gerenciar o redirecionamento quando combinado com o método registerRoute do Workbox e filtrar solicitações em request.mode === 'navigate' .

Um exemplo completo e mínimo se parece com isso:

Código do cliente

 import { preferences } from 'service-worker-i18n-redirect/preferences'; window.addEventListener('DOMContentLoaded', async () => { const language = await preferences.get('lang'); if (language === undefined) { preferences.set('lang', lang.value); // Language determined from localization user landed on } });

Código do trabalhador de serviço

 import { StaleWhileRevalidate } from 'workbox-strategies'; import { CacheableResponsePlugin } from 'workbox-cacheable-response'; import { i18nHandler } from 'service-worker-i18n-redirect'; import { preferences } from 'service-worker-i18n-redirect/preferences'; import { registerRoute } from 'workbox-routing'; // Create a caching strategy const htmlCachingStrategy = new StaleWhileRevalidate({ cacheName: 'pages-cache', plugins: [ new CacheableResponsePlugin({ statuses: [200], }), ], }); // Array of supported localizations const languages = ['en', 'es', 'fr', 'de', 'ko']; // Use it for navigations registerRoute( ({ request }) => request.mode === 'navigate', i18nHandler(languages, preferences, htmlCachingStrategy), );

Com a combinação do código do lado do cliente e do service worker, a localização preferida dos usuários será definida automaticamente quando acessarem o site pela primeira vez e, se navegarem para um URL que não esteja em suas localizações preferidas, serão redirecionado.

Adaptando a interface do usuário do site

Há muita coisa para adaptar adequadamente as interfaces do usuário, portanto, embora nem tudo seja abordado aqui, há um punhado de coisas mais sutis que podem e devem ser gerenciadas programaticamente.

Citações em bloco

Um padrão de design comum é ter aspas em bloco entre aspas, mas você sabia que o que é usado para essas aspas varia com a localização? Em vez de codificar, use open-quote close-quote para garantir que as aspas corretas sejam usadas para o idioma correto.

Formato de data e número

Tanto as datas quanto os números têm um método .toLocaleString para permitir a formatação com base em uma localização (idioma e/ou região). Os navegadores que oferecem suporte a eles são fornecidos com todas as localizações disponíveis, tornando-o facilmente utilizável, mas o Node.js não. Felizmente, o módulo full-icu para Node permite que você use todos os dados de localização disponíveis. Para fazer isso, após instalar o módulo, execute seu código com a variável de ambiente NODE_ICU_DATA configurada para o caminho para o módulo, por exemplo, NODE_ICU_DATA=node_modules/full-icu .

Metainformações HTML

Há três áreas em sua tag HTML e cabeçalhos que devem ser atualizados com cada localização:

• O idioma da página,
• Direção de redação,
• Idiomas alternativos nos quais a página está disponível.

O primeiro a ir no elemento html com as propriedades dir e lang respectivamente, por exemplo <html lang="en" dir-"ltr"> para inglês dos EUA. A configuração adequada disso garantirá que o conteúdo flua na direção certa e pode permitir que os navegadores entendam em que idioma a página está, permitindo recursos adicionais, como a tradução do conteúdo. Você também deve incluir links rel="alternate" para informar aos mecanismos de pesquisa que uma página foi totalmente traduzida, portanto, incluir <link href="/es" rel="alternate" hreflang="es"> em nossa página de destino em inglês deixe os mecanismos de pesquisa saberem que isso tem uma tradução que deve ser observada.

Projeto Intrínseco

A localização de conteúdo pode apresentar desafios de design, pois diferentes traduções ocuparão uma quantidade variável de espaço na página. Alguns idiomas, como o alemão, têm palavras mais longas que exigem mais espaço horizontal ou quebra de texto mais tolerante. Outros idiomas, como o árabe, têm fontes mais altas que exigem mais espaço vertical. Felizmente, existem várias ferramentas CSS para tornar o espaçamento e o layout responsivos não apenas ao tamanho da janela de visualização, mas também ao conteúdo, o que significa que elas se adaptam melhor a vários idiomas.

Existem várias unidades CSS projetadas especificamente para trabalhar com conteúdo. Existem as unidades em e rem que representam o tamanho da fonte calculado e o tamanho da fonte raiz, respectivamente. A troca de valores de px de tamanho fixo para essas unidades pode ajudar bastante a tornar um site mais responsivo ao seu conteúdo. Depois, há a unidade ch , representando o tamanho embutido do glifo 0 (zero) em uma fonte. Isso permite que você vincule coisas como width , por exemplo, diretamente ao conteúdo que ela contém.

Essas unidades podem ser combinadas com ferramentas CSS existentes e poderosas para layout, especificamente flexbox e grid, para componentes que se adaptam ao seu tamanho e layouts se adaptam ao seu conteúdo. Aprimorar aqueles com propriedades lógicas para bordas, margens e preenchimento em vez de propriedades físicas físicas faz com que esses layouts e componentes também se adaptem automaticamente ao modo de escrita. O poder do web design intrínseco (cunhado por Jen Simmons, unidades de reconhecimento de conteúdo e propriedades lógicas permite que interfaces sejam projetadas e construídas para que possam se adaptar a qualquer idioma, não apenas a qualquer tamanho de tela.

Localização (l10n)

A forma mais óbvia de localização é traduzir o conteúdo de um idioma para outro. Em formas mais sutis, as traduções não acontecem apenas por idioma, mas também por região em que é falado, por exemplo, inglês falado em americano versus inglês falado no Reino Unido, África do Sul ou Austrália. Para ter sucesso aqui, entender o que traduzir e como estruturar seu conteúdo para tradução é fundamental para o sucesso.

Estratégia de conteúdo

Há algumas partes de um projeto de software que são importantes para localizar e outras que não são. Nomes de classes CSS, variáveis ​​JavaScript e outros locais em sua base de código que são estruturais, mas não voltados para o usuário, provavelmente não precisam ser localizados. Descobrir o que precisa ser localizado e como estruturá-lo se resume à estratégia de conteúdo.

Estratégia de conteúdo tem muitas definições, mas aqui significa a estrutura do conteúdo, microcópia (as palavras e frases usadas ao longo de um projeto não vinculadas a um conteúdo específico) e suas conexões. Para obter informações mais detalhadas sobre estratégia de conteúdo, recomendo Estratégia de conteúdo para dispositivos móveis de Karen McGrane e Designing Connected Content de Carrie Hane e Mike Atherton.

Para o chromeOS.dev, acabamos codificando modelos de conteúdo que descrevem a estrutura do nosso conteúdo. Os modelos de conteúdo não são apenas para conteúdo longo, semelhante a um artigo; deve existir um modelo de conteúdo para qualquer entidade que um usuário queira especificamente de você, como um autor, documento ou até mesmo ativos de mídia reutilizáveis. Bons modelos de conteúdo incluem partes endereçáveis ​​individualmente, ou partes, de uma parte conceitual maior, excluindo partes que são tangencialmente relacionadas ou podem ser referenciadas de outro modelo de conteúdo. Por exemplo, um modelo de conteúdo para uma postagem de blog pode incluir um título, uma matriz de tags, uma referência a um autor, a data de publicação e o corpo da postagem, mas não deve incluir a string para trilhas de navegação ou o nome e foto do autor, que deve ser seu próprio modelo de conteúdo. Os modelos de conteúdo não mudam de localização para localização; eles são a estrutura do site. Uma instância de um modelo de conteúdo está vinculada a uma localização e essas instâncias podem ser localizadas.

Os modelos de conteúdo cobrem apenas parte do que precisa ser localizado. O resto – seus botões “Leia mais”, seu título “Menu”, seu texto de isenção de responsabilidade – é tudo microcópia. A microcópia também precisa de estrutura. Embora a criação de modelos de conteúdo possa parecer natural, especialmente para sites orientados a modelos, os modelos de microcópia tendem a ser menos óbvios e muitas vezes são esquecidos acidentalmente ao escrever o que é necessário diretamente em um modelo.

Ao criar modelos de conteúdo e microcópias e aplicá-los - por meio de um sistema de gerenciamento de conteúdo, linting ou revisão - você pode garantir que a localização possa se concentrar na localização.

Localize valores, não chaves

Modelos de conteúdo e microcópia geralmente geram estruturas semelhantes a objetos em uma base de código; sejam entradas de banco de dados, objeto JSON, YAML ou Front Matter. Não localize chaves de objeto! Se você tiver sua microcópia de texto de pesquisa localizada em um objeto de microcopy.search.text microcopy não a coloque em um objeto de microcopie.chercher.texte microcopie As chaves nos módulos devem ser tratadas como identificadores agnósticos de localização para que possam ser usados ​​de forma confiável em modelos reutilizáveis ​​e confiáveis ​​em toda a base de código. Isso também significa que as chaves de objeto não devem ser exibidas aos usuários finais como conteúdo ou microcópia.

Configuração de site estático

Para o chromeOS.dev, usamos Eleventy (11ty) com Nunjucks como nosso gerador de sites estáticos, mas essas recomendações para configurar um gerador de sites estáticos devem ser aplicáveis ​​à maioria dos geradores de sites estáticos. Onde algo for específico, será chamado.

Estrutura de pastas

Os geradores de sites estáticos que compilam com base na estrutura de pastas são particularmente bons no suporte ao método i18n de subdiretório. O 11ty também suporta uma cascata de dados com dados globais e um meio de gerar páginas de dados por meio de paginação, portanto, a combinação desses três conceitos produz uma estrutura de pastas básica semelhante à seguinte:

 . └── pages ├── _data ├── _generated └── {{locale-code}} ├── {{locale-code}}.11tydata.js ├── _data └── [...content]

Em um nível superior, há um diretório para armazenar as páginas de um site, aqui chamado de pages . Aninhada dentro, há uma pasta _data contendo arquivos de dados globais. Esta pasta é importante quando se fala de ajudantes a seguir. Então, há uma pasta _generated . Temos várias páginas que, em vez de terem conteúdo próprio, são geradas a partir de conteúdo existente, pequenas quantidades de microcópias ou uma combinação de ambos. Pense em uma página inicial, uma página de pesquisa ou uma página de destino de uma seção de blog. Como essas páginas são altamente modeladas, armazenamos os modelos na pasta _generated e os construímos a partir daí, em vez de ter arquivos HTML ou Markdown individuais para cada um. Essas pastas são prefixadas com um sublinhado para indicar que elas não geram páginas diretamente abaixo delas, mas são usadas para criar páginas em outro lugar.

Em seguida, subdiretórios l10n! Cada diretório deve ser nomeado para a tag de idioma BCP47 (mais comumente, código de localidade) para a localização que ele contém: por exemplo, en para inglês ou en-US para inglês americano. Na base de código chromeOS.dev, geralmente também nos referimos a eles como locales . Essas pastas se tornarão os subdiretórios de localização, segmentando o conteúdo para uma localização. A cascata de dados do 11ty permite que os dados estejam disponíveis para cada arquivo em um diretório e seus filhos se o arquivo estiver na raiz de um diretório e tiver o mesmo nome do diretório (chamado de arquivos de dados de diretório). 11ty usa um objeto retornado deste arquivo, ou uma função que retorna um objeto, e o injeta nas variáveis ​​disponibilizadas para modelagem, então temos aqui acesso aos dados para todo o conteúdo daquela localização.

Para ajudar na manutenção desses arquivos, escrevemos um auxiliar chamado l10n-data , parte de nosso scaffolding de site estático, que aproveita essa estrutura de pastas para construir uma cascata de dados localizados, permitindo que os dados sejam localizados aos poucos. Ele faz isso tendo os dados armazenados em um diretório de dados específico da localidade, o diretório _data nele (carregado no arquivo de dados do diretório). Se você olhar em nosso diretório de dados de localidade em inglês, por exemplo, verá modelos de microcópia como locale.json que define o código do idioma e a direção de escrita que será renderizada em nosso HTML, newsletter.yml , que define a microcópia necessária para nosso inscrição no boletim informativo e um arquivo microcopy.yml que inclui microcópia geral usada em vários lugares do site que não se encaixa em um arquivo mais específico. Em todos os lugares em que qualquer uma dessas microcópias é usada, nós a extraímos desses dados disponibilizados por meio da injeção de variáveis ​​de dados em nossos modelos para uso.

A microcópia tende a ser a mais difícil de gerenciar, enquanto o restante do conteúdo é basicamente direto. Coloque seu conteúdo, geralmente arquivos Markdown ou HTML, na subpasta localizada. Para geradores de sites estáticos que funcionam na estrutura de pastas, o nome do arquivo e a estrutura de pastas do conteúdo normalmente mapeiam 1:1 para a URL final desse conteúdo, portanto, um arquivo Markdown em en/web/pwas.md seria gerado em uma URL en/web/pwa . Seguindo nosso princípio de localização “valores, não chaves”, decidimos que não localizaríamos nomes de arquivos de conteúdo (e, portanto, caminhos), tornando mais fácil para nós acompanhar o status de localização do mesmo arquivo em todas as localidades e para que os usuários saibam eles estão na página certa entre diferentes localidades.

Ajudantes I18n

Além de conteúdo e microcópia, descobrimos que precisávamos escrever vários módulos auxiliares para facilitar o trabalho com conteúdo localizado. 11ty tem um conceito chamado filtro que permite que o conteúdo seja modificado antes de ser renderizado. Acabamos construindo quatro deles para ajudar no modelo i18n.

O primeiro é um filtro de data. Padronizamos que todas as datas em nosso conteúdo sejam escritas como um valor de data YAML porque as escrevemos principalmente em YAML e elas ficam disponíveis em nossos modelos como um carimbo de data/hora UTC completo. Ao usar o módulo e a configuração full-icu , a string de data (conteúdo que está sendo alterado), juntamente com o código de localidade do conteúdo que está sendo renderizado, pode ser passado diretamente para Date.toLocaleString (com opções de formatação opcionais) para renderizar uma data localizada. Date.toLocaleDateString pode ser usado opcionalmente se você quiser apenas a parte da data quando nenhuma opção de formatação for passada, em vez da data e hora localizadas completas.

O segundo filtro é algo que chamamos localURL . Isso pega uma URL local (conteúdo sendo alterado) e a localidade na qual a URL deve estar e as troca. Ele altera, por exemplo, /en/linux para /es/linux .

Os dois filtros finais tratam da recuperação de informações localizadas apenas do código de localidade. O terceiro aproveita o módulo iso-639-10 para transformar um código de localidade em nome de idioma no idioma nativo. Isso usamos principalmente para nosso seletor de idioma. O quarto usa o módulo iso-i18n-countries para recuperar uma lista de países nesse idioma. Isso é usado principalmente para criar formulários com listas de países.

Além dos filtros, o 11ty tem um conceito chamado coleções que é um agrupamento de conteúdo. O 11ty disponibiliza várias coleções por padrão e pode até criar coleções a partir de tags. Em um site multilíngue, descobrimos que queríamos criar coleções personalizadas. Acabamos construindo uma série de funções auxiliares para construir coleções com base na localização. Isso nos permite fazer coisas como ter coleções de tags específicas do local ou coleções de seções do site sem precisar filtrar nossos modelos em relação a todo o conteúdo do site.

Nosso auxiliar final e mais importante foram os dados globais do nosso site. Baseando-se na estrutura de subdiretório baseada em código de localidade, essa função determina dinamicamente quais localizações o site oferece suporte. Ele cria uma variável global, site , que inclui a propriedade l10n , contendo toda a microcópia e conteúdo específico de localização de {{locale-code}}.11tydata.js . Ele também contém uma propriedade de languages que lista todas as localidades disponíveis como uma matriz. Por fim, a função gera um arquivo JavaScript detalhando quais idiomas são suportados pelo site e arquivos individuais para cada entrada em {{locale-code}}.11tydata.js , codificados por localização, todos projetados para serem importados por nossos scripts de navegador. O trabalho pesado desse arquivo vincula nosso site estático ao nosso JavaScript front-end com a única fonte de verdade sendo as informações de localização que já precisamos. Ele também nos permite gerar páginas programaticamente com base em nossas localizações fazendo um loop sobre site.l10n . Isso, combinado com nossas coleções específicas de localização, nos permite usar a paginação do 11ty para criar páginas iniciais localizadas e de notícias sem manter páginas HTML separadas para cada uma.

Conclusão

Obter a internacionalização e a localização corretas pode ser difícil; entender como as diferentes estratégias e afetam a complexidade é fundamental para torná-lo mais fácil. Escolha uma estratégia de i18n que seja um ajuste natural para sites estáticos, subdiretórios e, em seguida, crie ferramentas para automatizar partes de i18n e i10n a partir do conteúdo que está sendo produzido. Crie conteúdo robusto e modelos de microcópia. Aproveite os service workers para localização independente do servidor. Junte tudo isso com um design que responde não apenas ao tamanho da tela, mas ao conteúdo. No final, você terá um site que seus usuários de todas as localidades vão adorar, que pode ser mantido por autores e tradutores como se fosse um simples site de localidade única.