Você desenvolve com a localização em mente?

Ao trabalhar em um projeto de software ou site, você desenvolve com a localização em mente?

Com isso eu quero dizer, por exemplo

• Externalizando todas as strings, incluindo mensagens de erro.
• Não usando imagens que contêm texto.
• Projetando sua interface do usuário com a expansão do texto em mente.
• Usando pseudo-tradução para testar sua interface do usuário no início do processo.
• etc.

Nos projetos em que você trabalha, eles estão na categoria 'bom ter' e deixam a equipe de localização se preocupar com o resto, ou você tem a disponibilidade de localização incorporada ao seu processo de desenvolvimento? Estou interessado em saber como os desenvolvedores veem a localização em geral.

Eu trabalho para uma grande empresa da Fortune 500 e sempre começamos com a localização em mente. Nossos projetos geralmente são apenas para os EUA, mas muitas vezes, ao longo dos anos, escreveremos um aplicativo para um cliente e depois alguém o verá e dirá "ei, isso seria um ajuste incrível para o país X". Então, a próxima coisa que você sabe é que está passando pelo código adicionando localização. Realmente não leva mais tempo para criar o aplicativo com ele desde o início, então é o que fazemos. Além disso, o benefício adicional é que, quando um cliente vem até nós e solicita que seu aplicativo esteja (escolha seu idioma), entregamos a ele um arquivo e solicitamos que ele seja traduzido (escolha seu idioma) e pronto .

Eu acho que isso foi importante 10 anos atrás. A tecnologia recente resolveu o problema .

Eu moro em um país onde há três idiomas nacionais e apenas um deles é minoria.

Para entender os problemas que podem ocorrer por causa disso, é como ter a parte oeste dos EUA falando um idioma (muito) diferente da parte leste. Pense que no centro do país, a população está um pouco mesclada e, portanto, você deve usar os dois idiomas em qualquer lugar.

Ter 4 idiomas em aplicativos e sites da área de trabalho era e ainda é muito comum (3 idiomas nacionais + inglês). Às vezes é uma obrigação.

Eu estava ciente da localização porque fui condicionada pelo meu ambiente. Então, sim, há alguns anos, eu estava preocupado com isso.

Agora, não me importo muito com localização, porque as ferramentas IDE mais recentes permitem converter qualquer aplicativo estático em um totalmente localizado com muita facilidade.

Ferramentas que eu uso com o Visual Studio .NET:

• CodeRush , um plug-in do Visual Studio que permite mover textos codificados para arquivos de recursos.
• Easy Localizer , extraia etiquetas em um arquivo do Excel no qual você adiciona todo o idioma adicional e, em seguida, mescla novamente os arquivos de recursos.

A maioria dos meus clientes exige apenas um idioma e, de fato, especifica esse idioma. Portanto, não gastamos tempo localizando o aplicativo. No entanto, isso não significa que podemos ignorar completamente outros idiomas. Então, continuamos com o básico:

• Use Unicode em qualquer lugar. É 2k10, não há desculpa para não fazê-lo.
• Design para alguma elasticidade no layout. Mesmo com todo o inglês, fontes diferentes têm pegadas de tela muito diferentes no mesmo tamanho de ponto.
• Mantenha as funções do aplicativo / modelagem de dados fora da camada de visualização

Pessoalmente, quando um potencial idioma de localização é fundamentalmente diferente daquele em que o aplicativo foi projetado, há muito mais acontecendo do que a simples seleção de texto. Embora a substituição de texto ajude e permita que uma empresa obtenha uma implementação "rápida e suja" em um novo local comparativamente mais cedo - ela não resolve as diferenças fundamentais na maneira como os usuários do outro idioma pensam.

Estudei japonês e, embora eu possa me considerar apenas um iniciante nesse idioma, sei o suficiente que existem alguns conceitos para os quais não há uma tradução direta. Existem idéias diferentes sobre o que torna algo útil. Embora os grandes conceitos principais possam ser semelhantes, são os detalhes que realmente fazem a diferença para os usuários.

Para realmente atender às necessidades de uma cultura muito diferente, você precisa de uma nova cara para sua aplicação. É por isso que a separação Modelo / Vista / Controlador se torna ainda mais importante. Desde que o aplicativo funcione da mesma maneira, a parte da vista pode ser completamente substituída. Quando isso acontece, alguém está planejando pagar algum dinheiro real para resolver o problema adequadamente.

Fizemos isso conforme necessário: as coisas voltadas para o cliente agora são todas feitas com a i18n, uma vez que expandimos nossos mercados, e algumas coisas internas agora são compatíveis com a i18n, portanto, os funcionários que usam isso não precisam falar inglês.

Então, fizemos isso conforme a necessidade, como uma startup.

Parece que as pessoas estão realizando os esforços da L10n com muita leveza. Especialmente ao usar o inglês como idioma original, é fácil ignorar o fato de que outros idiomas normalmente exigem até 30 a 40% de mais espaço para texto. Isso requer que os tradutores usem abreviações que não são fáceis de entender, o que é obviamente ruim para a experiência do usuário.

Normalmente, adiciono a internacionalização mais tarde quando preciso, mesmo que saiba desde o início que vou precisar. Com os idiomas que estou usando, não é muito difícil fazê-lo em uma fase separada, e posso manter um aspecto complicado fora das fases construtivas iniciais.

Eu escrevo aplicativos para Android e a localização é bastante direta, usando arquivos de string no estilo java. Esforço quase zero para a total internacionalização em todos os idiomas do Android.

Resposta: Sim. Embora no ambiente em que eu trabalho (Python / Zope / Plone) seja muito fácil localizar seqüências de caracteres posteriormente, pule isso se não for um requisito desde o início.

Mas eu guardo texto em objetos unicode, etc.

Então sim. Garanto que meus aplicativos sejam razoavelmente fáceis de localizar e, mesmo que não sejam localizados, funcionarão em um cenário internacional. Não fazer isso é um erro, pois o esforço necessário é pequeno e o benefício é grande.