Série globalização Mito - Mito 4: It Takes 6 SEMANAS para localizar um produto!

Este artigo foi escrito originalmente em Inglês. Texto em outros idiomas é fornecido através de tradução automática.
Introdução

A equipe do Adobe Globalização está empenhada em levar a melhoria contínua na experiência do cliente e melhorar a eficiência. Estas são duas das áreas de foco da Adobe para 2013.

O feedback topo cliente que costumava receber era que a localização dos nossos produtos precisava ser mais ágil. A equipe de vídeo digital, por exemplo, mudou-se para lançar produtos ingleses e localizada em um instapor exemplo a classe ; eles precisavam sim-GM, a fim de liberar rapidamente e atender as expectativas do mercado. Os produtos criativos clientes no Brasil e na Rússia, por exemplo, estavam ficando cansados ​​de esperar seis meses para ter em suas mãos um produto localizado. Como muitos na indústria, Equipe da Adobe globalização começou a enfrentar a pressão para localizar com menos recursos, reduzir o tempo de resposta de localização, e melhorar a qualidade.

Nosso desafio é atender as programações de lançamento agressivas de Mídia da Adobe Nuvens-Digital e Marketing Digital, seus produtos companheiro e ferramentas em 20+ línguas. Atualmente, nossa equipe usa, grosseiramente, 65% dos nossos recursos em localizações de Mídia Digital, e 15% localizações em Marketing Digital (20% é dedicado para Imprimir, ferramentas de desenvolvimento, financiar, e outras iniciativas). A equipe de localização é composta de aproximadamente 150 pessoas-gestores de programas internacionais, internacional engenheiros, engenheiros de qualidade internacionais, e estagiários localizados em os EUA, China, Índia, Japão, e na Roménia, apoio de aproximadamente 150 produto e equipes funcionais.

Neste artigo vamos mostrar como Adobe tem sido capaz de acelerar de localização e nós, esperançosamente, desmerecer a crença de que a localização tem 6 semana. Com orçamento limitado, estamos atendendo às expectativas, sim-transporte e Inglês 20+ idiomas para o Adobe baseados em nuvem produtos-Digital Media e Marketing Digital– Desenvolvedor / Web ferramentas, e toque em Aplicativos. Apoiamos qualquer fluxo de trabalho ágil e liberar horários podem ser tão curto quanto cada 2-4 semana (Photoshop.com, Acrobat.com, Gerente de nuvem, adoberevel.com), 6 semana (DPS, AdobeRevel), para lançamentos contínuos (CCM) variando de uma a duas vezes por semana mensal. Nestes fluxos de trabalho, podemos completar um ciclo de localização mais rapidamente dentro 24 horas. Nosso objetivo final? Estamos nos preparando para o dia em que os produtos da Adobe são liberados várias vezes por dia!

Amostra SCRUM Agenda - produto localizado sim-lançamentos em 20 línguas cada 6 semana

Lento é História! - Produto Preocupações da equipe no passado e Response Team Globalização

Modelos de desenvolvimento de produto da Adobe vêm em muitos sabores. Em geral, o modelo "cascata" foi considerado padrão. Produtos como o Photoshop, Acrobata, InDesign, e Illustrator estavam bem adequada para a localização padrão. Isso é, na UI Congelar marco, a equipe de localização iria intervir e começar o processo de localização. Isso significava que, GM pelo Inglês, as versões localizadas estavam ficando para trás por 4-6 semana.

Esta localização localização modelo de start depois UI Congelar tinha-marco vários inconvenientes. Parceiros de localização ficou sobrecarregado em jogo final; problemas de localização foram encontrados tarde demais e, quando as questões foram classificadas como "show-rolhas,"Eles poderiam comprometer o cronograma de lançamento do produto; muitos defeitos críticos acabaram ficando adiada para a próxima versão do produto. O modelo era caro, demorado, aumentou o desgaste e estresse.

Com o evento de multi-lingual instaladores, SaaS, Nuvem de produtos baseados, e novos fluxos de trabalho de desenvolvimento usadas por equipes de produtos Adobe, como o Scrum, Kanban, Scrumban, ou Aphid própria Adobe, a equipe de Globalização foi confrontado com novas exigências que pediram um fluxo de trabalho de localização mais acelerado. O novo modelo de negócios necessário que a localização deve ser possível em qualquer local, ser escalável para um grande conjunto de línguas, e respeitar várias restrições orçamentárias. As equipes de produtos começaram a questionar se a equipe de localização estava pronto para acompanhar o ritmo dos negócios. A resposta foi um grande "SIM, DE CURSO!"

Por razões de comparação de dois modelos diferentes, veja abaixo um cronograma localização cachoeira-modelo e uma programação de localização ágil a partir do mesmo período de 2004. O produto a seguir o modelo em cascata à esquerda, escolheu para enviar um único idioma versões em um calendário escalonado; o da direita, com base no modelo Aphid da Adobe, lançou o seu produto com um instalador multi-lingual como um único binário. Neste ponto no tempo, A globalização estava pronto para acomodar equipes tanto o produto.

Cachoeira – InDesign Agile – Audição

 

Com a aquisição da Macromedia em 2005, Localização Adobe enfrentou muitos desafios novos e excitantes. Dreamweaver, por exemplo, correu programas de pré-lançamento para todos os idiomas, o que significava que a localização tinha que ser logo atrás Inglês, no mesmo nível de desenvolvimento, teste, e estabilidade como Inglês. Graças aos muitos talentos que adquirimos e do nível de cooperação entre empresas, fomos capazes de alavancar as melhores práticas e atender as expectativas de as equipes de produto novo.

Em 2007, Adobe adquiriu Scene7, uma empresa de software permitindo que websites para ter em tempo real rich media; em seguida, Omniture, e 2009. Em 2010, Adobe adquiriu Software Dia, um líder de mercado na próxima geração de gerenciamento de conteúdo Web. Em 2011, web empresas, tais como ferramentas e Typekit Nitobi, o criador do PhoneGap; Fronteira Eficiente, uma empresa de marketing digital; e Iridas, o fabricante de SpeedGrade, um pedido de correção de cor profissional; e 2012, Adobe adquiriu Behance, a plataforma on-line líder para mostrar e descobrir o trabalho criativo.

Todos estes novos serviços baseados em nuvem exigiu velocidade de localização melhorada, principalmente através da internacionalização e automação. Os ciclos de desenvolvimento eram curtos - 2-6 semanas - e as atualizações eram freqüentes e com base na web. Nossa equipe precisava para mudar o foco, a fim de atender a esses requisitos baseados em nuvem do produto.

A equipe de Globalização, em parceria com as equipes de produto, trabalhou no sentido de um modelo de localização ágil. Aqui foram os primeiros passos que demos para a aceleração:

  • Produtos da Adobe foram assegurados World Ready — criou uma ferramenta de avaliação chamado Report Card Globalização (GRC) para determinar o cumprimento de prontidão mundo.
  • Engajado QE internacional no início do ciclo de desenvolvimento para testar e relatar bugs de internacionalização. Com isso, erros internacionais foram abordados de uma forma atempada, que ajudou a acelerar o ciclo de desenvolvimento e melhoria de produtos’ qualidade. Ver “Série globalização Mito - Mito 2: Este produto de software é apenas para os EUA” evidências sobre os benefícios de questões de internacionalização endereçamento no início do ciclo de desenvolvimento.
  • Trabalhou em cooperação com as equipes de desenvolvimento de novos para definir objetivos comuns e partilhar as melhores práticas. Esta cooperação resultou em melhores taxas de sucesso do que se localização foram consideradas como um pensamento pós-e como um time diferente.
  • Mudou a mentalidade – se temos conteúdo cedo e de forma iterativa, gostaríamos de localizar software e documentação de forma contínua. Produtos baseados em Cachoeira começou a trabalhar com a equipe antes da globalização UI Congelar marco. Começamos localizar kits glossário cedo e testando versões localizadas mais cedo do que no passado. Documentação equipe começou a distribuir off arquivos não-finais antes do usual "screen-shot de construção pronto" marco. Documentação localizada é agora enviada para a web, ao mesmo tempo que o produto versões em Inglês e localização de navio.
  • Desenvolvidos mais ferramentas - investidos em ALF (a estrutura de localização Adobe é um sistema de multi-camadas, cuja principal intenção é automatizar o processo de localização e facilitar a criação de produtos localizados), tradução automática (leva cordas em uma linguagem humana e automaticamente converte-los em outras línguas humanas), World Server (uma empresa de sistema de gestão de tradução e globalização, que permite a Adobe para simplificar e acelerar a nossa tradução e processos de localização por qualquer conteúdo, de nossos sites para conteúdo instrucional para aplicações de software e além), ferramentas que ajudaram a conseguir a localização de lançamentos rápidos quase em sincronia com o Inglês.
  • Envolvido nossos parceiros externos de localização mais cedo e começou a perícia crescente nesses times. Alguns de nossos vendedores agora são capazes de oferecer serviços de localização turnkey para produtos Adobe. Eles aprenderam os nossos produtos através de pré-lançamento, demonstrações de produtos, e treinamento por nossa equipe de Globalização.
  • Encontradas novas formas de interagir com nossos clientes através do Centro de Tradução Adobe, internacional de pré-lançamento, e fóruns. Estes clientes conhecer os nossos produtos de melhor, para que eles possam fornecer feedback inicial e podemos economizar tempo no longo prazo.

Com essas medidas em vigor, fomos capazes de chegar mais perto do horário produto Inglês e foram para trás por apenas um par de semanas.

Atualmente, a equipe de globalização reorganizou internamente para gerenciar o processo de localização para a experiência do cliente de ponta a ponta, que inclui software, marketing / conteúdo web, documentação, internacionalização / localização testes, e materiais educativos. Estamos mais bem alinhada e mais ágil, capaz de suportar a localização para os ciclos de produtos de 2-4 semana (Photoshop.com, Acrobat.com, Gerente de nuvem, adoberevel.com), 6 semana (DPS, Adobe Revel), para lançamentos contínuos (CCM) variando de uma a duas vezes por semana mensal. A fim de atingir estes horários desafiadoras, estamos transformando localizações em torno de 24 horas a tempos.

Por exemplo, Adobe Creative Cloud é lançado com 16 componentes localizados e sua agenda de hoje se parece com isso:

Padrão, grandes programações projetos como o Flash CS6, olhar como este:

Olhando para o futuro — Apresentando A.L.A., Aeroporto de Adobe

Um dos maiores desafios da globalização, é para cumprir o cronograma de liberação agressiva de Nuvens da Adobe, seus produtos companheiro, ferramentas da web, e aplicativos de toque em 20+ línguas.

Da mesma forma que os aviões têm de sair no tempo programado, tripulação e passageiros em lugar, num fluxo contínuo, assim como nossos produtos localizados, onde a equipe é formada por gestores de programas internacionais, Engenheiros internacionais de qualidade, Engenheiros internacionais e dos passageiros’ são os ativos (cordas) para tradução, a partir de qualquer número de produtos. O avião só pode estar indo para a França (dizer) ou pode estar a fazer paradas em numerosos países. A frequência de voos também irá variar, dependendo da demanda.

Antecedentes aeroporto

Começamos com projectos-piloto, principalmente projetos que precisavam localizações rápidas no final do jogo. Nossas necessidades foram:

  • Strings eram definitivas e revisada (corrigir provas)

Expectativas nossas equipes de produto 'foram:

  • Compatível com o Adobe traduções humana terminologia
  • Tradução rápida
  • Nenhum teste funcional / linguística

Note-se que embora a nossa ferramenta coleta cordas de vários produtos e os envia para os tradutores, podemos garantir consistência da terminologia e de qualidade, porque as cordas são primeiro alavancado através de World Server; e nossos tradutores fazer uso de nossos glossários para referência.

O Aeroporto de localização Adobe (A.L.A.) visa proporcionar uma hora de localização reviravolta. Nossa ferramenta de coleta cordas de vários produtos e os envia para os tradutores. Depois de traduzido, as cordas são distribuídos de volta para seus respectivos produtos, em breve!

Turn-around-time (TAT) - de Q2 2012 ao 1 º trimestre 2013, TAT diminuiu de uma média de 12.7 horas a 7.8 horas. Nosso objetivo, até o final do Q2 2013, é alcançar 1 TAT horas ou menos, caso o projeto exige que tanto a aceleração.

Aeroporto Turn-around-time por idioma, Para o quarto

Conclusão

A localização não é preciso 6 semana-que leva uma média de 7.8 horas. Nosso objetivo, no final do Q2 2013, é alcançar 1 TAT horas ou menos! Isso é um mito que temos desmascarado. As ferramentas e iniciativas da Globalização visam tornar a localização da Adobe ainda mais ágil, sem comprometer a qualidade de nossos produtos, bem como a satisfação do cliente.

____

Créditos:

O A.L.A. equipe Ajay Kumar, Guta Ribeiro, Joel Sahleen, John Nguyen, e Warren Peet
Jean-François Vanreusel
Leandro Reis
Megan Le Quynn

Série Mitos Sobre Globalização – Mito 3: O suporte de idiomas deve ser limitada à língua oficial(s) de um país

Este artigo foi escrito originalmente em Inglês. Texto em outros idiomas é fornecido através de tradução automática.

Declaração do problema

No campo globalização, observamos frequentemente casos em que as empresas misturam o uso de países e idiomas ao entregar produtos aos seus clientes globais. Suposições são feitas frequentemente que as pessoas que vivem em um país deve receber os serviços em linguagem mais comum desse país(s) - Tais como: - Japonês no Japão, Inglês nos Estados Unidos ou da Rússia na Rússia. Boas empresas vai mesmo apoiar situações multilingues, como Bélgica e Suíça, que suportam múltiplas línguas oficiais - mas é realmente bastante?

Neste artigo de blog, defendemos que os conceitos de "País" e "Língua" deve ser tratada à parte - mesmo que eles estão relacionados.

Línguas não têm fronteiras

Historicamente, línguas se espalharam ao redor do mundo através da imigração, invasões e colonização. É por isso que o espanhol é falado na América do Sul, Inglês nos Estados Unidos, Francês no Senegal e Canadá – só para citar alguns exemplos.

As línguas não têm sido limitados às suas terras em um longo tempo. Por exemplo, Espanhol e Português se espalharam para o ponto onde a maioria de seus falantes nativos são encontrados fora da Península Ibérica. Apenas 8.95% de falantes de espanhol são realmente os espanhóis [1]. Poderíamos argumentar que existem diferentes sabores de espanhol, Português ou francês, mas, em essência, essas linguagens são o mesmo e eles não estão confinados às fronteiras do país.

Twitter é uma ótima ferramenta para visualizar as línguas faladas em todo o mundo. Eric Fisher criou um mapa de linguagem legal usar o Twitter de dados [2], que mostra claramente as fronteiras sendo redefinidos. Catalão aparece nos países de mapas e multilingue, como a Bélgica desaparecer sob França e na Holanda.

Map of languages as used with Twitter

Figura 1: European Language Mapa – Autor: Eric Fischer

Línguas oficiais deixar algumas lacunas importantes,

Muitas empresas lançam produtos e serviços em um país e localização limite e recursos para a língua oficial(s) desse país. Em software, um exemplo típico é a criação de um novo produto para o mercado americano e limitar funcionalidades às necessidades de Inglês de língua dos usuários. Mas isso geralmente não é suficiente - mesmo se o mercado é limitado para os Estados Unidos.

Recent U.S. Os dados do Censo mostra que 60 milhão (ou 21%) dos norte-americanos com idades entre 5+ anos falam outra língua além do Inglês em casa. Espanhol leva uma grande parte do bolo com 25 milhão, mas idiomas como o chinês, Tagalog, Francês, Vietnamita, Alemão e coreano estão cada bem acima da 1 milhões de falantes marcar [5]. Isso é muito compreensível, considerando a história da imigração do país.

Além, o U.S. boas-vindas 59.7 milhão de visitantes internacionais em 2010 [6]. Destes, 33.4 milhões eram do Canadá e do México e 26.4 milhões de fora da América do Norte. Sabendo que esses estrangeiros gastam em média $4,000 durante a sua estadia, este segmento de mercado não deve ser ignorado.

Usando o índice de Greenberg, que mede a probabilidade de que 2 pessoas em um país que falam a mesma língua, The Economist mostra que a diversidade linguística está acontecendo em todos os países ao redor do mundo e, especialmente, em outras nações que os Estados Unidos, Rússia e China [7]. Também, Ethnologue.com é uma excelente fonte de dados em torno de adoções de linguagem.

Esta diversidade é também visível na análise da Adobe. Graças à Adobe Digital Marketing Suíte e nossa tecnologia de Entrega linguagem dinâmica, somos capazes de captar as línguas em que os nossos clientes em todo o mundo gostariam de receber produtos e / ou documentação. Figura 2 mostra as solicitações de idioma para Adobe Nav nos Estados Unidos. Os dados coletados com este pequeno aplicativo, basicamente, confirma a diversidade da população os EUA desde línguas como o espanhol, Árabe, Inglês Britânico, Coreano, Chinês Simplificado, Tradicional chinesa, Holandês, Russo e turco são todos solicitados pelos usuários localizados nos Estados Unidos.

Languages expected by DLD users

Figura 2 – Unsatisified pedidos de idioma para Adobe Nav nos Estados Unidos

Diversidade linguística em qualquer país é o principal motivo pelo qual os produtos de software deve ser desenvolvido com uma audiência global em mente. Mesmo se o interface do utilizador ou documentação é deixada em Inglês, área de trabalho, aplicações web e móveis deve pelo menos ser capaz de entrada, exibir e imprimir os caracteres para a maioria das línguas.

Similarmente, fomos capazes de capturar dados sobre os idiomas preferidos em Adobe.com. Estes dados confirmam que os países e línguas são dois conceitos separados - e enquanto a maioria dos clientes de um país ler o conteúdo na língua oficial, um pedaço grande de visitantes ainda preferem ler o conteúdo em um idioma diferente. Por exemplo, com a referência Action Script (ASR) orientar, notamos que, na Rússia, apenas 68% dos desenvolvedores de Flash preferem ler a documentação em russo contra 31% em Inglês (A linguagem não-oficial) e 1% em outros idiomas. Similarmente, desenvolvedores de Flash numerosos fora da Rússia optar por ler a documentação ASR em russo (Veja a figura 3).

Distribution of Russian Action Script Readers around the world

Figura 3 – Distribuição País de referência Action Script ler no idioma russo

Este é outro exemplo por suposições entre os países e línguas não deve ser feito.

Como as pessoas continuam a tornar-se mais móvel, é crítico para separar os conceitos de país e idioma. Esta mobilidade é o que se espalhou línguas para além das fronteiras e cria a necessidade de ter os idiomas suportados em todos os lugares.

A linguagem é uma preferência do cliente, que não podem ser limitados pelas fronteiras do país.

Conseqüentemente, se as línguas não têm fronteiras, bandeiras não devem ser usadas para representá-los como muitas vezes visto em web-sites. As bandeiras são a intenção de representar entidades políticas [3]. Um exemplo comum é a de representar o idioma Inglês com o britânico "Union Jack". Mas não é culturalmente sensível para falantes de inglês da Austrália, Índia ou Estados Unidos. Alguns têm abordado o problema através da mistura de bandeiras de vários países "em um, embora ele está tornando a situação ainda mais confusa. A bandeira abaixo (Figura 4) representa o idioma alemão (falado na Alemanha, Áustria e Suíça) e podemos imaginar o quão complicada a bandeira língua espanhola seria semelhante pois o espanhol é a língua oficial em 14 países [4] e falado em muitos mais!

Using flags to represent languages can become complex

Figura 4 – Bandeiras e Línguas (WikiMedia)

Take-aways

Em síntese, nós oferecemos 3 take-aways a considerar quando se lança um produto globalmente:

  1. Diferenciar os conceitos de "país" e "linguagem". Como tal, não usar bandeiras para representar línguas.
  2. Não se limite suporte para o idioma oficial(s) de um país / região. Alguns idiomas podem precisam de ser apoiados, embora não tenha estatuto oficial.
  3. Línguas não têm fronteiras e precisam de ser apoiados a nível mundial. Capturar linguagem preferida dos usuários(s) para que você possa atendê-los em sua língua, independentemente da sua localização.

Referências:

Série Mitos Sobre Globalização – Mito 2: Este produto de software é apenas para o U.S.

Este artigo foi escrito originalmente em Inglês. Texto em outros idiomas é fornecido através de tradução automática.

Em abril de, lançamos nossa série Mito Globalização por desmascarar o mito Globalização Internacionalização = Localização = Tradução =. Este tempo, vamos desmontar outra lenda urbana: ”Este produto de software é apenas para os EUA”

A declaração do problema(s)

Quando um novo produto de software está sendo projetado e implementado, muitas vezes ouvimos coisas como:

  • “Nosso produto é somente em Inglês, por isso não precisa se preocupar com a localização em tudo.”
  • “Não vamos nos preocupar sobre a localização de agora desde que a exigência do idioma inicial é apenas Inglês.”
  • “Vamos Inglês fora da primeira porta e vamos se preocupar com a localização mais tarde.”
  • “Estamos agora apenas focada em recursos, não localização.”

Também, nas indicações acima, o termo “localização” é muitas vezes intercambiável com “globalização” e “internacionalização”.

Isto é um pouco compreensível, desde que os Estados Unidos têm sido, historicamente, tanto o produtor superior e consumidor de produtos de software, e sua linguagem principal, Inglês, tem sido o mundo, a língua franca para mais de um século.

A verificação da realidade

Infelizmente, os pressupostos acima refletem uma mentalidade que produzem um impacto comercial negativo significativo a longo prazo. Eles são falsos a partir de várias perspectivas:

  • Muito frequentemente, produtos de software acabam sendo localizada. Você pode citar um produto de software comercialmente bem sucedido que é não localizado?
  • Mesmo se um produto nunca é localizada por causa da sua natureza – vamos dizer que é uma ferramenta de desenvolvimento – ou por causa da demanda de mercado pouco (por exemplo. alguns mercados em desenvolvimento), sua internacionalização é provavelmente importante por duas razões:
    • O conteúdo criado com o produto talvez precise ser localizada. Usando exemplos da Adobe, todos os dias milhares de clientes localizar camadas de texto de documentos do Photoshop, artigos de revistas criadas com o InDesign, texto em animações Flash, sites criados com o Dreamweaver, e internet rico ou aplicativo móvel criado com Flash Builder, em línguas Adobe não localizar os seus produtos em.
    • Certos mercados regionais têm requisitos específicos. Novamente usando os produtos da Adobe como exemplos, necessidades específicas de nossos clientes na Índia e no Oriente Médio tem motivado a adicionar suporte Indic e características bidirecionais InDesign CS6 para MENA, mesmo que ele não está localizado em árabe, Hebraico ou qualquer idioma índico. Também, nós incluímos suporte para Hanko no Acrobat, para refletir a forma como os documentos são assinados na Ásia Oriental.
  • Internacionalização torna-se mais caro mais tarde. Lembre-se do analogia motor de carro nós fornecemos em nosso artigo anterior mito? Assim, é fundamental que as equipes de desenvolvimento de produtos compreender as diversas necessidades de internacionalização, ea técnica, de recursos e tempo desafios para conhecê-los o mais cedo possível, de modo a evitar alterações de arquitectura dispendiosos e código de re-escreve mais tarde.

O maior custo de atraso internacionalização

Vários estudos gestão da qualidade total demonstraram os benefícios de problemas de endereçamento no início de um ciclo de desenvolvimento. Os mesmos princípios se aplicam à Internacionalização. A anterior, obtém considerado no ciclo de desenvolvimento do produto, melhor será a qualidade global do produto e mais barato os custos de desenvolvimento será.

Como mostrado no gráfico abaixo, o custo de internacionalização endereçamento durante o Design, Fases de codificação e teste são, respectivamente, 2, 3 e 4 vezes mais caro do que tratar internacionalização durante a fase de Requisitos.

Estas proporções obter pior, mesmo depois de o ciclo de localização começa (factor de 15x se o produto está localizado em 15 línguas) e os custos de abordar a internacionalização depois de alguns navios de produtos pode até se tornar astronómico (30 x).

Por exemplo, falta de definição e design de produto requisitos nas exigências e fases de projeto que atendam as necessidades dos clientes globais vai aumentar o custo de internacionalização em subseqüente fases (Codificação, Testes, e assim por diante) por causa do tempo adicional equipes de desenvolvimento de produto vai gastar com:

  • Reportagem internacionalização defeitos relacionados com a
  • Alterar ou re-escrever áreas impactadas pela internacionalização, tais como os manuseamento:
    • Datas, vezes, calendários, números, moedas, endereços, as unidades de medição
    • Interface de usuário cordas, o que pode requerer o uso de bibliotecas que fornecem externalização cadeia, e alterações em todos os códigos de carregamento cadeia (por exemplo. uma das equipes da Adobe dedicado 1 desenvolvedor para trabalhar 3 meses exclusivamente sobre esta tarefa)
    • Elementos de interface do usuário, tais como caixas de diálogo e paletas, o que pode requerer a conversão de utilização de bibliotecas de UI estáticos para aqueles dinâmicos.
    • Processamento de texto (entrada, exibir, saída, classificação, pesquisar), o que requer a adição do suporte Unicode – um código de baixo nível que requer grande re-teste – e pode exigir a adoção de um novo mecanismo de texto, uma grande mudança arquitetônica.
  • Em casos onde o trabalho de internacionalização é realizada versões do produto depois de muitos:
    • Desenvolvedores a começar a velocidade com código impacto que não poderia ter escrito originalmente, muitas vezes peneirando código legado que não pode estar em uso mais.
    • Áreas impactadas re-teste do código que foram lançadas em versões anteriores do produto
    • O gerenciamento de projetos de foco, 'De uma só vez’ esforços de internacionalização
  • Respondendo a pedidos e perguntas de clientes afetados sobre a falta de apoio para a sua língua (isso tem que ser explicado para cada novo cliente)
  • Gerenciando relacionamentos com os fornecedores de soluções de terceiros que poderiam ter previsto o apoio à internacionalização faltando, e com quem a empresa poderia ter entrado um acordo de divisão de royalties com

Também, pode haver custos indirectos que estão associados com:

  • Perda de receita potencial dos mercados que exigem a internacionalização
  • Exposição pública da falta do produto de internacionalização, quando os desenvolvedores de terceiros preencher a lacuna por comercializar as suas próprias soluções

Exemplos de apoio internacional em Inglês / não localizadas produtos

A melhor maneira de ilustrar a importância do apoio internacional em Inglês somente produtos é mostrar exemplos de produtos que tenham feito isso.

Um aplicativo de calendário

No primeiro exemplo abaixo, um idioma Inglês-calendário aplicativo oferece suporte para os calendários islâmico e tailandesas, permitindo que os usuários da Tailândia e 17 Países de língua árabe para usá-lo.

 

A aplicação nuvem de tags e um editor de texto

É muito importante que qualquer aplicativo que fornece a entrada de texto ou recursos de exibição suporte a caracteres de escrever outros sistemas que não o latim, o inglês ea maioria dos outros idiomas europeus se baseia em.

No exemplo seguinte, uma aplicação web-based tag cloud com uma interface de usuário Inglês-só permite aos usuários escrever caracteres de até 6 diferentes sistemas de escrita que representam centenas de línguas, selecionando fontes específicas.

O editor de texto baseada em desktop abaixo suporta perto de 20 sistemas de escrita, o que significa praticamente ninguém no mundo pode digitar com a versão em Inglês do produto.

Um site de viagens

A seguir, Inglês-UI site de viagens oferece um bom exemplo de como moeda, formatos de data e hora estão correctamente adaptadas para seus usuários alemães.

Os benefícios do design global

Em síntese, projetistas de produtos raramente deve imaginar seus produtos de software como “U.S. apenas”. Existem muitos benefícios para pensar globalmente desde o início:

  • Você será capaz de cumprir todas as exigências de localização de novos negócios em muito menos tempo e com custo muito menor. Quando se trata de localização, na economia globalizada de hoje, muitas vezes não é uma questão de “se”, mas uma questão de “quando”.
  • Você será capaz de vender seus produtos para clientes no mundo inteiro, em oposição aos vivo apenas no U.S. ou em países de língua Inglês, mesmo se o seu produto não é localizada (ainda).
  • Projeto de arquitetura global e codificação é um investimento one-time, e é muito menos dispendiosa do que posterior re-arquitetura e re-codificação.

Nosso mito globalização próxima será publicado no próximo mês. Entretanto, você tem alguma bons exemplos de internacionalizados Inglês-somente os aplicativos que você gostaria de compartilhar? Deixe-nos saber!

Ver também

Mito globalização – Mito 1: Globalização Internacionalização = Localização = Tradução =

Série Mitos Sobre Globalização – Mito 1: Globalização = Internacionalização = Localização = Tradução

Este artigo foi escrito originalmente em Inglês. Texto em outros idiomas é fornecido através de tradução automática.


Provavelmente, o maior equívoco que encontramos ao falar com alguns colegas de fora da equipe de globalização da Adobe é que “Globalização”, “Internacionalização” e ”Localização” significam a mesma coisa, e essa coisa é de alguma forma relacionada com algo qualquer um pode entender: Tradução.

Não podemos culpar os nossos colegas por tais crenças equivocadas, já que estes termos têm sido usados ​​e abusados ​​por gerações.

Provavelmente não ajuda que também existem termos em uso, tais como “Culturalização”, “World-Readiness”, ”Glocalização”, “Transliteração”, “Transcrição”, “Localizability”, e “Japonização”.

O fato de cada um destes terem abreviaturas correspondentes (por exemplo. G11n, I18n, L10n, T9n, C13n, L12y) e também grafias diferentes (“Globalisation”, “Internationalisation”, “Localisation”, e assim por diante) apenas ajuda a tornar a coisa toda mais assustadora e confusa para os "civis".

Este artigo pretende esclarecer essas diferenças, e fornecer uma melhor compreensão dos vários passos que compõem o software globalização.

Esclarecendo a terminologia

Vamos concentrar nossas explicações em torno de alguns termos básicos fundamentais que geram mais confusão. Uma coisa a ter em conta é que, embora o significado de algumas tarefas, como a "tradução’ e 'localização’ são padrão na indústria, alguns outros termos como "globalização’ e 'internacionalização’ não são. As definições dadas aqui são os predominantes (que usamos na Adobe).

Internacionalização (comumente abreviada como I18n) é um exercício de engenharia focada em generalizar um produto de modo que ele pode lidar com vários idiomas, scripts e convenções culturais (moeda, regras de classificação, formatos de número e de datas ...) sem a necessidade de redesign. Internacionalização, por vezes referido como world-readiness, pode ser dividida em dois conjuntos de atividades: enablement e localizability.

Localização (L10n) é o processo de adaptação de um produto ou serviço para a aparência e experiência de um determinado idioma, cultura, e local desejado “look-and-feel ". Traduzindo interface de usuário do produto é apenas uma etapa do processo de localização. Redimensionando Caixas de diálogo, botões e guias de paleta para acomodar cordas mais traduzidos também faz parte da localização.

Tradução (T9N) é simplesmente a conversão do significado do texto em uma língua para outra. Em um produto de software, o conteúdo que é traduzido são a interface de usuário, documentação, colaterais de embalagem e comercialização. A maioria da tradução é feita por profissionais, embora nos últimos anos, algumas empresas começaram a explorar o uso de 'community'-tradução, e tradução automática.

Globalização (G11N) refere-se a uma ampla gama de processos de engenharia e desenvolvimento de negócios necessárias para preparar e lançar produtos e atividades da empresa em todo o mundo. As atividades de engenharia globalização são compostas de internacionalização e localização, enquanto as atividades de desenvolvimento de negócios foco em gestão de produtos, financeiro, marketing e aspectos jurídicos.

World-Readiness é um termo equivalente à Globalização, mas é mais frequentemente usado no contexto de internacionalização.

Como eles se relacionam entre si

O diagrama simplificado abaixo ilustra a relação entre os principais atividades relacionadas à globalização .

Em síntese, no contexto de software:

  • Tradução é uma parte do Localização
  • Internacionalização é um pré-requisito de Localização
  • Internacionalização e Localização são partes Globalização
  • Globalização inclui muitas atividades relacionadas aos negócios fora do próprio produto.

Uma analogia na vida real

Ainda com dificuldade para entender? Vamos fazer uma analogia com um produto com o qual todo mundo está familiarizado : um automóvel.

O Toyota Corolla é um dos carros mais bem sucedidos de todos os tempos. Mais de 30 um milhão deles foram vendidos no mundo. Mas, não se seus fabricantes não tivessem adotado os princípios básicos da globalização nos anos 60, o Corolla dificilmente seria conhecido fora do Japão hoje.

Assim, para alcançar tal sucesso,, a Toyota teve que:

  • aceitar no início a idéia de que eles queriam alcançar mercados fora do Japão. Eles montaram uma rede mundial de comercialização no país, organização de vendas e suporte ao cliente. (Globalização)
  • Projetar e desenvolver um carro que poderia ser facilmente adaptado para outros mercados geográficos com custo mínimo e esforço (Internacionalização)
  • Adaptar carros para mercados geográficos específicos. Por exemplo, para os EUA, Canadá e grande parte da Europa, o volante e pedais foram facilmente movida para o lado esquerdo do carro sem alterações estruturais. (Localização)
  • Fornecer manuais de instruções na língua do mercado. (Tradução)


Exemplo de localização de uma interface de automóvel

Onde está o problema

Então, qual é o impacto dessa generalização '’ de terminologia para o processo de globalização de software?

O principal problema é que a maioria das equipes de produtos olhar a globalização como um processo único e monolítico que ocorre algum tempo depois da concepção e implementação do produto Inglês, e de propriedade de uma única equipe (a "Globalização’ equipe). Essa mentalidade incentiva uma “throw-over-the-wall” abordagem que muitas vezes resulta em:

  • Engenharia núcleo adicional e esforço de teste para resolver questões de internacionalização crítico foi encontrado no final da programação
  • Engenharia de localização adicional e esforço de teste manualmente para lidar com questões localizability
  • Maior número de defeitos do produto
  • Atrasos no cronograma
  • Experiência mais pobre cliente

Usando a analogia do automóvel na seção anterior, um “throw-over-the-wall” abordagem significaria que, para adaptar um Toyota Corolla projetado para clientes japoneses ao mercado americano, engenheiros seria necessário para mover o motor ou o sistema de suspensão, a fim de mover o volante e os pedais a partir do lado direito para o lado esquerdo do carro – uma operação dispendiosa e demorada.


Internacionalização ajuda a evitar que este

A história curta (pontos a lembrar)

  • Globalização, internacionalização e localização são atividades relacionadas, mas diferentes, realizadas por equipes diferentes em fases diferentes de desenvolvimento de produto
  • Incorporar globalização em seu pensamento o mais cedo possível. Começe durante o design. Pergunte a si mesmo: que os mercados em todo o mundo que eu estou visando a curto prazo e longo prazo? O que esses clientes precisam? Se você só pensar em mercados de hoje você vai ignorar a globalização.
  • Implementar um produto internacionalizado, mesmo se você não acha que vai vender fora os EUA. ou a não-Inglês de língua clientes, porque esta decisão pode facilmente mudar e, em seguida, as alterações vão ser muito caro. Se o seu produto é successul em um mercado, você provavelmente terá grandes oportunidades de negócios no exterior. Assim, plano para ela.
  • A internacionalização deve ser realizada principalmente pelo produto da equipe de engenharia do núcleo. Faça isso uma vez, fazê-lo direito, em seguida, entregá-la a localização.
  • O processo de localização será muito mais fácil e mais barato se o produto é bem internacionalizado.

As corporações mais bem sucedidas globais instilado globalização como parte de todos os seus funcionários’ “DNA”. Para que uma equipe da empresa ou produto para ser bem sucedido internacionalmente, primeiro deve haver uma decisão consciente de executivos eo buy-in de todos os envolvidos na concepção e desenvolvimento de um produto de software para ir internacional. Isto significa que, a menos que o produto e toda a infraestrutura em torno dela não estão prontos para capitalizar as oportunidades presentes em um mercado internacional, o potencial de receita global do produto nunca será plenamente alcançado, ou a um custo proibitivo somente.

Ver também

Série Mitos Sobre Globalização – Mito 2: Este produto é apenas para o U.S.