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


13

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.


3
L10N-> localização ... vamos usar o inglês adequado aqui, não é?
Rook

11
@Rook - É uma abreviação comum da indústria e está contida no 'The American Heritage® abreviaturas Dictionary' - então eu gostaria de ouvir sua definição de 'inglês adequado' (observe a capitalização de 'inglês' :-)).
Jimmy Collins

5
@Rook E está escrito Localização também;)
Rowland Shaw

2
@ Jimmy C - Não no Black, nem no Longman, nem no Oxford, nem no Merrian ... (e, acredite ou não, tive o trabalho de verificar todos eles apenas para ter certeza). Mas, claramente, é feio e não se assemelha a uma palavra (não tenho certeza, mas sou muito forte com as palavras que não têm números).
Rook

4
@Rook: É uma abreviação de numerônimo. O mesmo é i18n para "internacionalização" e g11n para "globalização". Eles são feios? Talvez talvez não. Fato é que eles são de uso comum.
Andy

Respostas:


9

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 .


Verdade. Mas para projetos pessoais, não. Apenas inglês.

6

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.

4
Verdade? quais ferramentas permitem isso?
precisa

E quanto a coisas como texto em imagens e o uso de strings como (por exemplo) 'Your High School' em formas que podem não ser entendidas em determinados locais? Um desenvolvedor ainda precisa estar ciente das diferenças culturais.
Jimmy Collins

No Visual Studio, eu uso uma ferramenta do DevExpress chamada CodeRush. Há também outra ferramenta que eu uso para traduzir um aplicativo inteiro de uma vez: Easy Localizer: foss.kharkov.ua/products/easy_localizer/index.htm (os adicionarei para referência na minha resposta)

4
boas ferramentas, mas há mais do que isso - os layouts de tela, por exemplo, podem precisar ser alterados devido a diferentes comprimentos de etiqueta; os valores de pesquisa do banco de dados precisarão ser traduzidos; etc.
Steven A. Lowe

@ Steven & JimmyC: aqui não há balas de prata. Apenas boas ferramentas que removem a maior complexidade. Observe que notei um padrão com anos de trabalho em aplicativos localizados: Você não pode saber antecipadamente quanto tamanho uma determinada palavra ou sentença terá nos idiomas que você não conhece. Acredite, eles podem ter tamanhos muito diferentes. Você ajusta suas interfaces e layouts durante seus testes.

4

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.


+1 por seguir o básico e seu ponto de vista sobre Unicode. Além disso, você faz um bom argumento sobre 'muito mais do que a simples seleção de texto'. Isso é especialmente verdadeiro ao localizar aplicativos para idiomas escritos da direita para a esquerda (como árabe ou hebraico), onde toda a interface do usuário precisa ser espelhada.
Jimmy Collins

Do ponto de vista da usabilidade, o simples espelhamento da interface do usuário pode não ser a melhor opção. Pode ser necessário reorganizar alguns elementos para cumprir as convenções locais e reduzir a curva de aprendizado para seus usuários. Projetos sérios de internacionalização / localização precisam considerar o impacto nos usuários nesse local. Caso contrário, o aplicativo não receberá a adoção que os profissionais de marketing esperavam.
Berin Loritsch

3

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.


2

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.


1

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.


2
Não tenho certeza se essa é a melhor abordagem - e se você receber solicitações para alguns idiomas que possam ser problemáticos, talvez para alguns idiomas de byte duplo como japonês, coreano etc.?
Jimmy Collins

1
Jimmy C: Atualmente, para o tipo de projeto em que estou trabalhando, o suporte a idiomas europeus como inglês, alemão, francês, espanhol, polonês etc. é suficiente. Eu simplesmente não sei o suficiente sobre japonês e outras línguas "problemáticas" (por exemplo, instruções para escrever etc.) para fazer todos os preparativos necessários no software; e não faz sentido gastar grandes quantidades de tempo e dinheiro com algo que provavelmente nunca acontece de qualquer maneira. BTW, byte duplo não é nosso problema, usamos Unicode em qualquer lugar: D
user281377

Faz sentido nesse cenário, eu acho.
Jimmy Collins

Você realmente não precisa saber muito sobre árabe e japonês para se preparar para a internacionalização. Existem diretrizes gerais que geralmente são boas o suficiente. Se você suporta vários idiomas europeus e usa Unicode, provavelmente está na maior parte do caminho.
David Thornley 1/1

1

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.


É verdade que as novas tecnologias de plataforma foram projetadas com a localização em mente. Na minha experiência com o iOS, é um procedimento bastante simples para localizar esses tipos de aplicativos.
Jimmy Collins

1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.