Journey Automação no mundo da L10n!!

Journey Automação no mundo da L10n!!

Feb'14, Reetika Ghai

Automate

As conversas blog sobre a importância da automação no mundo da localização e sua maior necessidade no mundo de Agile

Mudança de Paradigma de Cachoeira para o Agile no Mundo de Localização

Você sabe qual é o animal terrestre mais rápido do mundo, alcançando velocidades de até 113 kmh?

Ao longo dos últimos dois anos, tem havido uma mudança gradual no Software Development Life Cycle (SDLC) metodologia para a maioria dos produtos de proa Adobe. Gestão de produtos passou de um ano do ciclo de vida de desenvolvimento de produtos à base de cachoeira para correr metodologia Agile (baseado em desenvolvimento iterativo e incremental, onde os requisitos e soluções evoluem através da colaboração entre a auto-organização, equipes multifuncionais).

Como resultado da evolução das tendências do mercado, precisamos reinventar a nossa abordagem ao teste de localização para atender as novas exigências de metodologia Agile. No Agile, ciclos de desenvolvimento e de teste são mais curtos, com rápido tempo de resposta. Na localização, volumes de teste têm picos considerando a duração do ciclo de Sprint 2-3 semana. Características requerem validação frequente em vários locais e plataformas antes de certificar para um lançamento em um modelo de lançamento simultâneo (sim-GM). No âmbito Agile, é importante estar ciente dos objetivos de negócio do ponto de vista de localização. Eu classificaria estes em três grandes áreas:

  1. Tempo em caixa lançamentos freqüentes ao mercado: Com ágil a maioria dos produtos da Adobe ter pelo menos um lançamento a cada trimestre para uma freqüência tão elevada como lançamentos semanais / mensais
  2. Âmbito teste Aumento levando ao aumento de esforços de localização: Com cada sprint o escopo legado para certificar LOC construção aumenta
  3. Maior foco no desenvolvimento rápido característica nova com lançamento simultâneo ao mercado: Certificação recursos em plataformas N Local e M em um sprint de 3-4 semana

Esses objetivos criar os seguintes desafios para uma Internacional de Engenharia de Qualidade (IQE) equipe ao decidir o escopo na localizada constrói para testes de localização:

    • Garantir uma maior cobertura de teste sobre os novos recursos, equilibrando a cobertura para áreas de recursos legados
    • Garantir a possibilidade de reutilização de testes em várias variantes da plataforma
    • Garantir a precisão do teste através de cenários repetitivos em vários idiomas
    • Garantir a execução mais rápida de descobrir defeitos no início
    • Certifique-se de todos os recursos funcionam como esperado em todas as plataformas suportadas e localidades
    • Certifique-se de co-existência de diferentes versões dos produtos / patches lançados
    • Certifique-se de enviar o produto ao mesmo tempo em todas as localidades com suporte em todo geografias (sim-GM)
    • Assegurar a cobertura do teste otimizado em todas as localidades com suporte e variantes da plataforma

 

Automação em Agile & Localização

Por que o teste de automação em Localização?

- Vários lançamentos em um ano

- Alto volume de testes

- Complexidade da Plataforma: Combinação local

- Cobertura de teste melhorada levando a uma melhor qualidade

- Escalabilidade

- Mais rápido tempo de mercado

- Eficácia de Custos

Com estes pensamentos iniciais, propusemos para expandir a cobertura de automação de recursos de produto do Dreamweaver de língua Inglês para idiomas localizados em setembro 2012. Nosso objetivo inicial era atingir 45% cobertura automação característica em versões localizadas no que diz respeito à cobertura em Inglês construir na plataforma Mac.

Aos poucos, nós construímos as capacidades de automação de recursos nos próximos seis meses, a partir permitindo a estrutura de automação para a localização (ou seja, adicionou suporte à estrutura de automação para executar scripts do sistema operacional localizada) para a execução de testes de fumaça diárias em todo o 15 idiomas suportados, e, eventualmente, ter uma boa cobertura de automação ao nível de recursos.

Automação é uma ótima maneira de superar os desafios acima e, efetivamente, atingir a cobertura do teste optimizados em localização constrói. Com a automação, seria possível certificar incrementais versões criativas de nuvem para todos os sistemas operacionais suportados e combinações linguísticas apoiar os lançamentos com prazos.

Com vários lançamentos para o mercado em um ano, execução manual do escopo de teste reproduzível pelos fornecedores de localização leva ao aumento dos esforços de teste. A maior parte do aumento do esforço de teste pode ser atribuído ao aumento incremental âmbito teste legado, ou seja, âmbito legado é cumulativo a soma de todas as entregas no passado de um produto e aumentaria com cada sprint. Por outro lado, testes automatizados pode ser executado repetidamente garantindo cobertura definida através de plataformas e combinações linguísticas, contribuindo assim para a qualidade geral do produto para o tempo de liberação em caixa. Isto não só elimina a redundância de teste, mas também ajuda a produzir resultados de teste mais rápidos.

Tendo a área do legado automatizada ajudaria o testador localização focar manualmente o atual Sprint entrega, portanto, descobrir defeitos no início do teste cycle.The IQE preciso ser cauteloso ao decidir o escopo da automação em versões localizadas. Priorizando a cobertura de automação é muito importante.

A cada lançamento trimestral de mercado, o escopo de certificação dos recursos herdados definidos para um produto está aumentando, levando a amplificado esforço de teste reproduzível em vários sprints em comparação com um tempo de validação no modelo de lançamentos anual

Legacy Automation Coverage

Journey into Dreamweaver Automação

Equipe DW Localização tem 88% Cobertura Funcional & 86.5% de cobertura condicional núcleo cobertura w.r.t de 50% cobertura condicional e funcional na versão CC para MAC!

Para a adopção de automação produto em idiomas localizados, nossa jornada olhou, respondendo a algumas de nossas perguntas iniciais:

  • Quais são as características que precisamos para automatizar?
  • Qual será a seqüência de automação característica?
  • O localidades que devemos considerar para começar, com base em dados da história de pré-lançamento e bug?
  • Qual seria a melhor abordagem para a cobertura do teste otimizado nas diferentes localidades?
  • Na estrutura de automação, Onde deve ser as cordas específicas localidade (usado em scripts de teste) ser colocado? Ou devemos puxar as cordas diretamente para comparação do Adobe Localização Quadro (ALF) em tempo de execução?
  • Como é necessário muito esforço para a adoção de automação em localidades?
  • Qual seria a configuração inicial necessário para iniciar a automação nas diferentes localidades?
  • Quanto é necessário um esforço adicional para a execução de scripts de automação em versões localizadas regularmente?
  • Quais serão as necessidades de hardware e o desafio de encontrá-los?
  • Qual deve ser a frequência de automação é executado (fumaça diariamente, plano característica básica, e novo plano de recurso)?
  • Como ter o melhor tempo de resposta de execução em todas as localidades? Qual deve ser a matriz de otimização considerando tempo de resposta rápido em ágil?

Inicial 6 meses jornada para adoção da estrutura de automação para localização Dreamweaver

Time chart

Automation Framework Dreamweaver

Automação Dreamweaver é baseado na estrutura de automação caseiros Adobe chamado de 'Jerry '. O quadro foi desenvolvido pela equipe de Dreamweaver Inglês QE. Ele foi escrito em Java Núcleo, suportado por scripts de maçã e scripts java no backend, fazendo uso da API do Dreamweaver exposto pelos desenvolvedores.

DW framework


O diagrama mostra o fluxo de trabalho de automação:

Passo 1: Um tíquete de trabalho (contém detalhes de configuração como TC #, Plataforma, Detalhes da máquina, informações sobre o idioma, etc) é alimentado ao servidor PULPO.

Passo 2: Servidor Pulpo objetivo principal é o gerenciamento de máquina e registro de resultado. Servidor Pulpo invoca a máquina de teste com base e executa a automação de teste com base no plano mencionado no tíquete de trabalho.

Passo 3: Uma vez que a execução é concluída os log / resultados são copiados para o servidor Pulpo, para posterior análise.

Passo 4: Os resultados são registrados no painel de automação "AutoDash"

O quadro Jerry contém casos de teste automatizados agrupados sob vários planos de teste:

Fuma diariamente - Teste básico para a validação da compilação diária

Plano de recursos básicos - Contém casos de teste do legado e novas áreas de cobertura de fumaça recurso no Studio Test

Plano de Aceitação - Contém aceitação e cobertura de passagem de teste completo para os recursos desenvolvidos no legado e presente ciclo de lançamento no Studio Test

Começamos com uma máquina iMAC dedicada à automação Dw. Contudo, logo após a prova de conceito foi bem sucedida, nós adicionamos uma máquina mais dedicado para automação em versões localizadas. Os planos de teste acima foi executado em uma base pré-programado em todos os 15 localidades no plano de execução predefinido. Bilhetes de trabalho distribuídos em 15 localidades foram alimentados com o servidor Pulpo manualmente ou automaticamente e foram acionados na chegada de novas construções no Codex. Tipicamente, no momento em que chegou ao escritório, construir sanidade foi concluída em todas as localidades e estávamos bom compartilhar as compilações com os nossos parceiros fornecedores.

Para o monitoramento e otimização de cobertura de teste através 15 línguas, um calendário de execução específica foi seguido. Com base no calendário, diferentes planos de teste automação foram executados em várias combinações locales / plataforma em uma base diária. Teste de fumo diário para validação de construção foram executados, seguido de passagem de teste dedicado full característica nos fins de semana. A execução foi pré-agendada ea cobertura do teste foi distribuído entre as localidades para melhores resultados, dado o tempo e as limitações da máquina.

Realizações & Aprendizagens

Realizações

Na Nuvem Criativa (CC) lançamento, que se beneficiou de ter teste automatizado passa localizada constrói através 15 línguas:

  • Eficiência global de cobertura de teste melhorou quatro dobras em comparação com a execução de teste manual
  • Teste de sanidade rápida para a aceitação de construção de localização antes de passar a compilação parceiros fornecedores aumento da eficiência
  • Alcançados rápido tempo de resposta para o teste característica básica de scripts de automação
  • Certificação paralelo em várias compilações (Patch e linha principal constrói)
  • Mais foco na parte nova desenvolvimento características do sprint atual pelos testadores funcionais de localização
  • Certificação de pré-lançamento de construção completamente através da automação
  • Construído projeto e código de verificação Sign através da automação em todas as localidades em 2 horas em comparação com 32 horas de verificação manual

Aprendizagens

  • O apoio da equipe principal: É essencial ter a automação abençoado da equipe de Inglês para suporte ideal. Em caso de Dreamweaver, temos imenso apoio da equipe, especialmente de Kiran Patil (Gerente da Qualidade) e Arun Acidente (Sr. Chumbo Qualidade) para dirigir os esforços de automação em versões localizadas
  • Piloto em estrutura de automação para uma locales 1/double-byte/Cyrillic camada para garantir o quadro era robusto e iria apoiar automação na maioria das localidades
  • Sempre documentar as questões / desafios que enfrentamos durante a criação de automação, eles sempre agir como um ponto de referência mais tarde
  • Garantir os scripts básicos são independentes das cordas Inglês. No Dreamweaver, atualizar os scripts de automação legado para fazer esses scripts são executados na localização foi um grande desafio, como scripts de automação estavam falhando em comparações de strings. Aishvarya Suhane (Localização Automação QE) foi uma grande ajuda para escrever funções na estrutura de automação e criando alguns novos scripts para resolver questões específicas de localização.

Chitas no mundo da localização …

Um agradecimento especial a Guta Ribeiro para inspirar & tutoria me a escrever o meu primeiro Blog & Rakesh Lal por seu apoio.

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

GALA Webinar sobre Gerenciamento de Projetos de Localização

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

Manish Kanwal, Gerente do Programa Internacional da Adobe será a realização de um webinar em GALA (Globalização e Localização Associates), que é a maior organização sem fins lucrativos padrões dentro da indústria da língua. O webinar vai apresentar esclarecimentos sobre as melhores práticas para gerenciar um projeto de localização complexa. Adicionalmente, ele vai elucidar com um estudo de caso de um projeto abrangente grande com equipes de engenharia espalhados por todo o mundo, incluindo, linguística, revisores, legal, cadeia de suprimentos, marketing, de apoio ao cliente e muito mais.

Junte-se a este webinar para aclimatar o que é preciso para projetar gerenciar e localizar em condições exigentes, direito a partir do ponto o produto está previsto até ao seu lançamento público. Detalhes do evento estão disponíveis aqui, será transmitido em 26 de Julho 11:00 EDT

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 =

InDesign CS6 .... Bem-vindo à Índia!

Este artigo fala sobre o objetivo geral de localização em um novo mercado em termos de negócios ou um "mercado emergente". Você pode se perguntar, "Por que a palavra específica Emergentes?"Por causa da oportunidade de negócio que apresenta tomando um produto para um novo mercado onde a demanda existe, mas de alguma forma o produto não foi disponibilizado.

No domínio de publicação, A Índia é ainda um dos poucos países onde Impressão tem observado um crescimento constante. Trechos de uma pesquisa do site famoso abaixo:

"Contrariamente à maioria dos outros mercados no mundo que continuam a testemunhar uma erosão da indústria de mídia impressa, na Índia, o setor presenciou um crescimento de 10 por cento em 2010 e deverá continuar a crescer a um ritmo semelhante ao longo dos próximos cinco anos. O aumento dos níveis de literacia e de baixa penetração de mídia de impressão oferecem margem significativa para o crescimento, diz um relatório FICCI-KPMG, recentemente lançado no FICCI FRAMES 2011 evento ............ "[Fonte Tudo sobre jornal, data de publicação de Março de 2011 `]

Será que este presente uma oportunidade para a Adobe para expandir no espaço Print Media alavancando seu um dos mais populares software InDesign Editoração ®. Sim, mas a que custo? Vamos pesar os custos e benefícios.

  1. Ao longo de últimos anos, Adobe Índia força de vendas vem se reunindo clientes indianos para entender como o InDesign pode ser feita "a Índia está pronto '.
  2. Na Índia, Inglês é muito perto de ser a segunda língua mais falada, atrás Hindi, dando uma margem de manobra para, provavelmente, ainda chegou ao mercado com uma interface de usuário Inglês (UI).
  3. O mais falado área nas reuniões com clientes freqüentes foi o apoio de scripts índicos de impressão e aplicativos de desktop Publishing da Adobe. Os actuais World-prontos compositores para Oriente Médio texto incluído suporte parcial para scripts índicos vários. Contudo, uma série de correções de bugs e requisitos de suporte de produto foram necessários para a Adobe para certificar oficialmente e lançar o produto na Índia.

As especificações listadas acima que esculpir um caminho para o InDesign para ver suporte para scripts índicos em CS6 liberação. Baseado na entrada do Gerenciamento de Produtos, o seguinte 10 Scripts de indianos a classificação mais elevada na lista de prioridades para apoiar:

Cada uma das localidades acima tem uma boa porcentagem de mídia de impressão no mercado indiano variando de jornal, Revistas, Revistas, etc. Para apoiar essas localidades era um caminho difícil pela frente já que a maioria dessas localidades usam combinação de caracteres complexo, glifos, regras de hifenização, suporte de dicionário.

Fase 1 deste projeto incluiu suporte de dicionário adicionando no InDesign para essas localidades. Nós integramos as específicas da localidade dicionários de código aberto, avaliados os contra produtos concorrentes (com o suporte semelhante) abrangendo uma série de dados de script de teste específicos escolhidos a dedo por lingüistas. Os critérios de teste sendo:

  • Maturidade de teste e qualidade dos dicionários incorporados
  • Ortografia palavras intencionalmente e comparar as palavras corrigidas
  • Verifique se as palavras em InDesign quando copiados manter sua santidade
  • A validação de um regime linguístico poucos, conforme aplicável, tais como hifenização, colchão, grafias, etc

Dicionário avaliação mostrou resultados bastante impressionantes, permitindo-nos passar para segunda fase deste esforço de analisar InDesign para scripts índicos. Depois de um número significativo de fluxos de trabalho complexos, uma engenharia poucos belisca ao longo do caminho, fomos capazes de conseguir aquilo que nós colocamos nossos olhos no início.

  • Dicionários adicionados e verificadores ortográficos para o 10 roteiros
  • Hifenização acrescentado para o 10 roteiros
  • Incluído 1 Família de fontes Indic: Adobe Devanagari
  • Incluído um script que os usuários podem executar para definir padrões relevantes e lidar corretamente com as importações a partir de documentos do Word etc.

Mesmo que nós começamos este esforço como um projeto de sementes, codinome como Indic InDesign 1.0, fomos capazes de conseguir mais do que nós filmamos para. InDesign não provou apenas compatível para a maioria das localidades listadas acima, mas ofereceu apoio notável, mesmo para os glifos mais complexos.

Mude para o Compositor do Mundo-Ready, um mecanismo de composição alternativa, com um único clique de indicPreferences.js em Janela > Utilitários > Scripts painel para explorar o mundo Indic no InDesign. Em virtude de suporte básico Indic script em InDesign CS6, agora você pode digitar esses idiomas e caracteres iria moldar e processar corretamente. E sim, haverá mais refinamentos ao apoio Script Índico em versões futuras que virão.

Deixe-nos saber o que você pensa e como você pretende usar esses recursos. Por favor visita aqui para a lista completa de suporte de idiomas no InDesign CS6.

Contribuição de Harpreet Singh (Adobe Índia)

Anunciando Programas PSE11 e PRE11 para usuários franceses e alemães

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

Programas de Pré-lançamento da Adobe são uma oportunidade para experimentar, avaliar e influenciar os próximos produtos & tecnologias da Adobe dentro de um , ambiente de usuário mais focalizado. Programas de Pré-lançamento facilitar um processo de desenvolvimento simbiótico permitindo Adobe compartilhar produtos em fase de desenvolvimento para recolher feedback inicial. No processo, você tem a chance de moldar a futuros produtos e adaptar aos novos produtos mais rapidamente.

Canais múltiplos de noivado estão disponíveis para os participantes pré-lançamento da Adobe:

  • O acesso para baixar o software de pré-lançamento / tecnologias e documentação técnica
  • Capacidade de reportar bugs & solicitar recursos para o software de pré-lançamento
  • O acesso aos fóruns de usuários de pré-lançamento para compartilhar idéias diretamente com as equipes de produtos Adobe e outras likeminded gente da comunidade do produto
  • Oportunidade de participar de vários produtos relacionados com inquéritos

Um programa de pré-lançamento é uma tentativa de envolver os usuários reais do produto - você - no início do ciclo de desenvolvimento do produto, para ouvir e aprender com vocês sobre como o produto está funcionando para você.

Oportunidades atuais de pré-lançamento: Como se inscrever?

Você pode preencher os formulários de candidatura para expressar seu interesse em aderir ao programa de pré-lançamento de um produto da Adobe. A participação será inteiramente com base nos requisitos do programa e as credenciais do participante.

Seguintes produtos foram abertas oportunidades de testes de pré-lançamento com Francês e alemão constrói:

Photoshop Elements 11 para usuários francês- Inscreva-se agora para participar do programa Adobe Photoshop Elements localizada e funcionalidade de visualização novo e excitante! - Inscreva-se agora

Photoshop Elements 11 para usuários alemães - Inscreva-se para participar do Programa Photoshop Adobe Elements Localizada e visualização novas funcionalidades emocionante! - Inscreva-se agora

Premiere Elements 11 para usuários francês - Inscreva-se para participar no Adobe Premiere Elements 11 Programa localizada e visualizar a nova funcionalidade interessante! - Inscreva-se agora

Premiere Elements 11 para usuários alemães - Inscreva-se para participar no Adobe Premiere Elements 11 Programa localizada e visualizar a nova funcionalidade interessante! - Inscreva-se agora

Nós aguardamos a sua participação neste programa de pré-lançamento. Em caso de qualquer problema de se precisar de mais informações, por favor não hesite em contactar Manish Kanwal em mkanwal@adobe.com ou Ninra Khan no nikhan@adobe.com.

 

Adobe Flash – Criação de Conteúdo & Diretrizes de localização

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

1. Objetivo deste documento
Este blog é um resultado de um extenso estudo realizado para identificar as melhores práticas na localização de conteúdo Flash baseado em.

Localizando conteúdo estruturado através de ferramentas de gerenciamento de tradução (como SDL WorldServer) pode ser um processo simples. No entanto conteúdos não estruturados, como o texto que aparece em vídeos em Flash não é fácil. Para adicionar a ele, monitoramento da eficiência dos lingüística se torna ainda mais difícil para conteúdo não-estruturado.

O blog cobre todos os aspectos da localização do Flash incluindo a criação do conteúdo Inglês do jeito certo; de modo que ela se torna localização “amigável ". Isso deve resultar em redução de custos e tempo; que é multiplicado pelo número de línguas-alvo deve render dividendos suficientes.

2. Extração de texto a partir de uma animação em Flash

A dificuldade de localização do Flash animação depende do nível de globalização da fonte – geralmente Inglês animações em Flash. Durante o processo de localização, todo o texto localizável é extraído da animação fonte, substituídos por versões localizadas e strings localizadas são modificadas de acordo com as guias de estilo- escolha, incluindo o tamanho da fonte, família etc. Ocasionalmente texto localizável não está incluído nas camadas de texto, mas apresentados como gráficos. Portanto, a animação fonte tem que ser fixado em primeiro lugar para tê-lo pronto para a localização. Como primeiro passo do Flash localização animação é extrair todo o texto localizável da animação. Isso é possível utilizando ferramentas comerciais como "ferramenta de localização Flash" ou fonte de renomeação. Fla arquivo para o arquivo zip. (apenas mudar a extensão de. fla para. zip) e extrair todos os arquivos. xml a partir de "biblioteca" subpasta do zip.. Veja a figura 1 e Figura 2 para mais detalhes.


Figura 1 - Lista de Flash arquivo com subpasta BIBLIOTECA

Figura 2 -. Lista de camadas de texto em formato xml armazenado na subpasta biblioteca de um arquivo Flash

Formato Flash nativo é um arquivo zip com estrutura definida. Ter um conhecimento baisc de que permite que sejam facilmente extrair todas as camadas de texto da animação. Uma vez feito, a única tarefa continua para localizar o texto dentro dos arquivos extraídos. xml e fornecer os tradutores com. ini (se a tradução está a ser concluída usando CAT Trados). Camadas de texto em arquivos XML pode ser encontrado rodeado por <caracteres>Seu texto</caracteres> Tags XML.
As lojas XML as informações sobre o tamanho da fonte, família e estilo (Além de armazenar o texto localizável). A maioria desta informação como a família da fonte pode ser facilmente modificado para todo o texto se fonte de origem não suporta o alfabeto do idioma alvo. Para mais detalhes sobre o Flash arquivo XML por favor veja a Figura 8.

Best Practice # 1:
Nunca modifique os textos dentro de camadas de texto com a ajuda do script de ação. Vai ser difícil de compreender roteiro.

3. Pseudo localização
"Localização Pseudo" é um processo para garantir a animação está pronto para localização e todos os textos localizáveis ​​está nas camadas de texto apenas. Durante este processo, todas as cordas atualmente contido em camadas de texto (.xml) são substituídos por pré-definida cadeia, por exemplo. por "X". Arquivos originais. Xml na subpasta BIBLIOTECA são substituídos por outros modificados e quando essa ação é concluída, render.swf deve ser reproduzida em Flash player. Ao jogar estes processa é possível localizar qualquer texto restante que não foi pseudo localizada por várias razões.
Texto originalmente presente nas camadas de texto é exibido como "X" neste renderização. No caso de haver ainda qualquer texto legível, geralmente, vem de vídeo embutido, gráficos ou um script de ação. Pode-se encontrar exemplo de localização pseudo na Figura 3, Figura 4 e Figura 5.

Figura 3 – Exemplo de localização pseudo. Todas as seqüências, exceto “O que há de novo” foram alteradas para “X”. “O que há de novo” é uma gráfica em animação em Flash e, portanto, não podem ser facilmente editadas.

Figura 4 – Imagem mesmo, como na Figura “3″ mas agora localizada em russo. Como você pode ver também “O que há de novo” está corretamente localizado. Neste caso fonte foi fixada e localizáveis ​​textos gráficos foram atualizados para as camadas de texto.

Figura 5 – Outro exemplo de localização pseudo. Bem apresentado é um screenshot de um aplicativo e o único texto editável está no canto superior direito. Neste caso específico, Decidiu-se não a fingir-lo e deixá-lo em Inglês, como o tamanho da fonte era muito pequena

Best Practice # 2:
Aplicar localização Pseudo para descobrir não whichis qualquer texto localizável em camadas de texto dentro do Flash projeto. Se o seu projeto foi globalizado, desde a forma ideal, localisation pseudo pode ser skiped.

 

4. Camadas de texto em animação em Flash
Há muitas maneiras para inserir texto em animação em Flash. Por exemplo, evitar a inserção de texto gráfico (letras como objetos gráficos) e trabalhar com camadas de texto apenas. Se este for o caso, Não quebre o texto em várias cadeias, e mantê-lo em uma única cadeia, se as exigências específicas. Qualquer separação de substrings múltiplos resultará segmentação intext dentro. Arquivo xml e pode levar à perda de contexto durante a tradução e localização, portanto, incorreto dele é substring.
Na Figura 6 e Figura 7, pode-se encontrar texto "Os clientes fiéis como você economizar com o preço de atualização especial. Adobe Photoshop Elements & Adobe Premiere Elements é agora um perfeito 10!"
Esta frase é separado em duas camadas diferentes do texto. Tal separação resultará em segmentação de strings no arquivo xml. Bem e tradutor vê-los como duas cordas separadas, sem qualquer relação entre eles, veja a Figura 8.

Figura 6 – "Os clientes fiéis como você economizar com o preço de atualização especial. Adobe Photoshop Elements & Adobe Premiere Elements é agora um perfeito 10!"Separação de texto em duas substrings. Nesta figura, a primeira parte é visível.

Figura 7 – Segunda parte do texto "Os clientes fiéis como você economizar com o preço de atualização especial. Adobe Photoshop Elements & Adobe Premiere Elements é agora um perfeito 10!"

Figura 8 – Representação de substrings no arquivo xml.. Cada substring está incluído no <DOMStaticText> dentro de tag. arquivo xml.

Não é recomendado para dividir uma string em substrings mais curtos, mas sim mantê-los em uma camada de texto, sempre que possível. As vantagens desta abordagem são:
1. String localizada é bem ordenada para que substrings localizadas não precisam ser revisados ​​pelo falante nativo após a localização e postprocess.
2. Cadeia não é dividido em substrings mais curtas dentro. Arquivo xml.
A versão atual do Flash permite aos autores manter cordas com a família de fonte diferente, cor, estilo, tamanho etc. em uma camada de texto. Adicionalmente, não há necessidade para separá-los em várias camadas de texto. Mantendo strings em uma camada de texto ajuda os tradutores e engenheiros de localização para gastar menos tempo na tradução e pós-processamento de seqüências localizadas na animação. Ele também diminui a chance de questões relacionadas à ordem das palavras. Na Figura 9 você pode encontrar exemplo de cadeia complexa (parte do texto está em amarelo com fonte maior) em uma camada de texto.

Figura 9 – Seqüência complexa de uma camada de texto apenas. Não há necessidade de colocar o texto em amarelo em uma camada de texto separado. Com o Flash de hoje você pode criar tais seqüências complexas.

Melhor Prática #3:
Manter o número de camadas de texto dentro de projeto do Flash o mais baixo possível. Se qualquer formatação de texto é necessária, fazê-lo apenas uma camada de texto (, tanto quanto possível).

 

5. Vídeos incorporados
Muitas vezes, Animações em Flash pode conter vídeos incorporados. Estes vídeos incorporados podem ser facilmente encontrados em Flash biblioteca de objetos sob o título "Vídeo incorporado" tipo, por favor veja a Figura 10.
Se houver quaisquer segmentos a ser localizado dentro de vídeos incorporados e apenas de render o foi fornecido, será muito difícil e tempo para localizar tais cordas. Em casos especiais, quando o vídeo é cuidadosamente analisado, algum texto pode ser "falsificado" com pequeno esforço.
Contudo, texto animado (Figura 11) ou um estático com fundo em movimento é quase impossível para editar e para localizar este tipo de fonte é necessário gastar muitas horas para falsos apenas um ou dois segundos do render final. A fonte simplesmente precisa ser recriado o que aumenta o colector de esforço.
Com o arquivo editável vídeo um projeto pode modificar todas as camadas de texto dentro de vídeo embutido e preparar versões localizadas desses vídeos.

Figura 10 – O vídeo incorporado “soccer.flv” com seqüência de caracteres localizável animado

Figura 11 – Exemplo de texto localizável dentro do vídeo incorporado impossível de falsificar, texto é animado

Best Practice #4:
Vídeos incorporados com textos localizáveis ​​no projeto do Flash aumentar o tempo e esforço para colector de localização.
A melhor maneira de fazer é extrair todo o texto do vídeo, localizá-lo, substituir todos os textos localizáveis ​​e criar renderização localizada primeira. Sem arquivo de vídeo editável, a única (pungente) opção é tentar texto falso dentro de vídeo embutido, que é geralmente impossível. Então NÃO incorporar text / ativos em vídeos se você quiser localizá-lo. Fornecer bens e vídeo separetely vez.

6. Capturas de tela Animações
Pode-se também criar uma animação flash dentro do projeto de uma série de screenshots. Veja o exemplo da série de imagens na Figura 12 e Figura 13. Texto nas imagens são os localizáveis ​​e uma fonte. Psd com camada de texto editável precisa ser criado inicialmente. Uma vez concluída eo texto está substituído com uma versão localizada, screenshooting da série localizada pode ser realizada.
Se você tem o código fonte editável. Psd disponível, forneça ao seu engenheiro de localização. Além disso, efeitos de texto usados ​​no Flash localizada serão idênticas às do Flash fonte.

Figura 12 – Série Screenshot. Você pode ver os dois pré-visualização da tela e também seqüência de imagens na timeline do Flash

Figura 13 – Fim da série de tela na animação em Flash. Texto “O Big …” é animado dentro da série e cada imagem acrescenta uma letra do texto na animação.

Best Practice # 5: Para qualquer Localizable texto dentro de alguns gráficos (texto gráfico), é importante para fornecer ativos de origem inglesa. Se bem-fonte editável não é fornecido, tem que ser re-criado por fornecedor de localização primeiro a ser capaz de substituir o texto por uma versão localizada e criar renda para o Flash projeto. Durante a re-criação de ativos de origem editável alguns efeitos podem ser supervisionado e, portanto, perdeu na versão localizada.

 

7. Botões & Camadas ativos
É vital para manter todos os botões com textos localizáveis ​​como tipo "Movie Clip" no projeto do Flash e não usar mistura de tipos diferentes de Flash para simular a funcionalidade do botão. Se a funcionalidade do botão consiste em mais tipos de Flash, é muito provável que, durante o processamento pós, os engenheiros podem usar inadvertidamente alinhamento incorreto desses objetos em relação uns aos outros dentro de determinado período de. Como resultado, isso levará a um impacto funcional no arquivo flash, e, em alguns casos, rending ele corromper
Um exemplo de botão corrompido é descrito na Figura 14. Aqui o botão consiste em um texto gráfico na caixa amarela e camada ativa (mostrado como uma moldura azul) que desempenha papel de área "clicável". Você pode observar que a caixa não está alinhado com camada ativa e do lado esquerdo desse botão não será clicável. Adicionalmente, lado direito contém uma área sobreposta que é ativo, que não está correto.

Figura 14 – Botão corrompido “O que há de novo”. Camada ativa (moldura azul) não está alinhado com caixa amarela.

Criação de botões como "Clipe de Filme" vai evitar problemas semelhantes em animações Flash. Às vezes, modificação do script de ação atribuída é necessário, bem.

Best Practice #5:
Camadas de ativos fora do botão em Flash pode levar a desalinhamentos em versão localizada do Flash. Exige uma vez para redimensionar botão e objetos da camada de ativos a cada mudança no não. de caracteres de texto no botão. Botões criada corretamente eliminar os riscos potenciais de desalinhamento e diminuir o número de botão re-colas por um número significativo.

 

8. Vacilante
Em alguns players em Flash, texto localizada podem apresentar “Flickering efeito "ou seja, texto é movido por um ou um pixel para a esquerda poucos, direito, cima ou para baixo quando o cursor é passado sobre ele. Veja a figura 15 para mais detalhes.

Figura 15 – A tremulação em detalhes - a imagem é composta de duas imagens da mesma peça re-capturados depois de alguns segundos mais tarde para ver se muda a posição do pixel

A única maneira de corrigir a "cintilação" A questão é converter as camadas de texto dentro de projeto do Flash localizada em curvas e processar em formato final. Texto gráfico (curvas) não mostra o “Flickering efeito "mais

Best Practice #6:
Cintilação efeito é visível em alguns jogadores apenas. É recomendado o uso de jogadores Flash sem cintilação efeito. Caso contrário, camadas de texto localizados têm que ser convertidos em curvas antes da renderização em formato final. Quando multiplicado pelo número de línguas-alvo, esforço vai passar a ser enorme.

 

9. Agradecimentos / Créditos

Este documento foi elaborado a partir de um estudo independente feito no Photoshop Elements 11 por James Skrabal & Petr Knápek de Morávia, e Akulaa Agarwal & Manish Kanwal da Adobe.

Por favor, note que ele pode ser aplicado a todos os projetos Adobe / Adobe não exigindo a localização de texto e outros ativos em arquivos Flash. Para quaisquer questões, sinta-se livre para chegar aos Akulaa Agarwal(akulaa@adobe.com) e Manish Kanwal (mkanwal@adobe.com).

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.

 

Está chegando: Série mitos de Globalização

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

A partir deste mês, vamos publicar uma série de artigos sobre os mitos da globalização.

Se você já trabalhou na indústria da Globalização o tempo suficiente, provavelmente já ouviu muitos dos mitos que vamos descrever.

Se você é novo ou de fora da indústria, então espero que esta série vai ajudar a esclarecer a situação..

O primeiro artigo será publicado em breve. Fique ligado.