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.

Cadastre-se: 3rd Adobe Experience Manager Multilingual Interesse Especial conteúdo Reunião do Grupo de

A equipe de Inteligência de Conteúdo multilíngüe Adobe está animado para sediar a terceira Adobe Experience Manager Multilingual conteúdo Special Interest Group (SE) reunião na quinta-feira, Novembro. 7, em nossa sede em San Jose. Nosso programa desta vez é em Digital Asset Management (DAM), e pretendemos concentrar em como DAM pode ser usado para fins multilingues. Durante a reunião, nós também vamos ter um gerente multi site (MSM) rever sessão para compartilhar planos de aprimoramento do recurso para futuros lançamentos.

Esta é uma grande oportunidade de compreender os conceitos básicos da DAM e relacionados melhores práticas em um contexto multilingue. Os participantes também vão acotovelar com os nossos especialistas da Adobe, compartilhar suas experiências e desafios, e interagir com colegas de várias empresas líderes da indústria que estão colocando Adobe Experience Manager para usar.

Os detalhes:

Data: Quinta-feira, Novembro. 7, 2013

Tempo: 8:30 AM - 4:30 PM PST
Endereço: Sede Adobe San Jose
345 Park Avenue
San Jose, CA, 95110

O evento é gratuito, mas você deve se registrar com antecedência para participar. Para a inscrição, visite: https://adobesig.eventbrite.com

Para mais informações ou quaisquer dúvidas, Você está convidado a me pingar no: seunlee em adobe.com

Nós esperamos vê-lo na próxima semana!

Seungmin Lee

Sr. Gerente do Programa

Cinco regras de ouro para conseguir a localização Agile

Ilustrações por Julia Feng (OhISeeItNow.com)

Agile_Loc_LogoAo longo da última década, muitas equipes de desenvolvimento de software mudaram sua metodologia de desenvolvimento de um modelo em cascata para algo muito mais ágeis, como Scrum. Através desta transição, suas expectativas em relação a outras equipes, como localização mudaram e essas equipes tiveram que melhorar a sua agilidade também.

No Adobe, temos um grupo de localização centralizada, que atualmente suporta 135 produto e equipes funcionais. A maioria dessas equipes adotaram alguma forma de metodologias ágeis de desenvolvimento e reduziram o seu ciclo de desenvolvimento de 18-24 meses a anual, trimestral, mensal e, nos dias de hoje, lançamentos bi-semanais. Um casal de equipes de produtos Adobe e outras empresas estão até lançando versões atualizadas do seu produto várias vezes por dia, tornando-se imperativo para localização de continuar a melhorar a sua agilidade.

Elaborado a partir de nossa experiência, este artigo apresenta Cinco Regras de Ouro que precisam ser satisfeitas para conseguir a localização ágil ideal.

Regra 1 - "Somos uma equipe!"

Dentro de muitas empresas, Adobe incluiu, A localização é uma função centralizada de todo o produto que serve e funcional (por exemplo. Marketing, De vendas, Legal, e assim por diante) equipes. Esta estrutura faz sentido, porque a localização é um campo especializado, Portanto, os recursos (pessoas, ferramentas) e os processos podem ser aproveitados por toda a empresa. Todavia, localização ainda deve ser preocupação de todos. A equipe de localização pode chegar a muitas soluções, mas os melhores originam quando há uma verdadeira parceria entre as equipes de produto / funcional e localização.

We're one team!

Nós somos uma equipe!

As equipes mais ágeis tratar pessoal localização, como se fosse parte de sua própria equipe.

Um aspecto central do Scrum é incluir todos os conjuntos de habilidades, incluindo localização, obrigado a entregar um produto para usuários. Portanto, Membros da equipe de localização deve ser incluído em todos os aspectos de desenvolvimento – de avaliação backlog de retrospectiva – para que eles pudessem planejar e resolver questões internacionais desde o início. Parcerias fortes também devem ser estabelecidas com fornecedores de localização quando as empresas, como Adobe, interagir com parceiros e fornecedores para a sua tradução e atividades de teste.

Envolvimento do cliente é um aspecto fundamental de metodologias ágeis como ele valida a qualidade e utilidade do trabalho realizado até o momento. Recomendamos que você se envolver com clientes internacionais também, porque seus problemas de aumentar a conscientização em torno da internacionalização.

Em síntese, todas as partes interessadas (equipes de desenvolvimento, equipes funcionais, incluindo localização, fornecedores e clientes) precisam colaborar estreitamente a fim de alcançar grande agilidade.

Regra 2 - "A internacionalização é rei"

No nosso Série Mitos Sobre Globalização, definimos Internacionalização (comumente abreviado como i18n) como 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, número, data e hora formatos ...) sem a necessidade de redesign.

Internationalization is King

Em outras palavras, o melhor internacionalizado um aplicativo é, o mais fácil será para localizar.

No modelo em cascata, equipes poderia contornar algumas das deficiências de internacionalização por causa de ciclos de desenvolvimento mais longos. Infelizmente, no mundo ágil, não há tempo suficiente para procurar trabalho em torno de soluções mais. O código precisa ser internacionalizada a partir do get-go.

Existem várias abordagens para melhorar a internacionalização de uma empresa, que inclui o seguinte:

  • I18n_EducationEducação: Desenvolvedores do núcleo de treinamento é uma forma eficaz de reduzir o número de questões de internacionalização em um produto. Ao expor os engenheiros para questões de localização e internacionalização, eles ganham uma perspectiva mais ampla sobre o impacto de seu código e evitar algumas das armadilhas de internacionalização clássicos.

 

  • I18n_LibrariesBibliotecas de internacionalização: Aproveitando bibliotecas de internacionalização Open Source, como UTI ou JavaScript i18n, é outra boa prática. Em vez de re-inventar a roda, engenheiros podem reutilizar o código que já foi validado por outros. Também, bibliotecas i18n normalmente suportam 100+ local, que requerem uma quantidade significativa de investigação e desenvolvimento vez. Vai ser difícil para uma única equipe ou até mesmo da empresa para suportar tantas localidades.
  • Peer_ReviewRevisão de código: Praticar avaliações pelos pares é um método eficaz para reduzir os defeitos de internacionalização em um produto. Desde desenvolvedores sabem o seu código será revisto, que prestar mais atenção à sua qualidade (efeito da pressão dos pares) por isso também beneficia internacionalização. Algumas empresas chegam a automatizar esse processo de revisão usando ferramentas como o Globalyzer.
  • Globalization Report Card: Produtos de benchmarking contra uma arquitetura ideal ajuda a melhorar a internacionalização também. Como parte de nosso programa de World-Readiness, nós criamos um sistema Report Card Globalização para avaliar o grau de mundo prontidão em cada produto Adobe. Este scorecard mede produtos contra um conjunto de critérios de internacionalização (capacidade de entrada de caracteres internacionais, exibir os formatos de data, traduzir a interface do usuário, e assim por diante ...). É uma forma eficiente de acompanhar o progresso feito por cada equipe ao longo do tempo e pode até mesmo criar uma competição saudável entre as equipes de produto. Essas equipes são motivados a estar no topo das paradas da i18n!

Globalization Report Card

Regra 3 - "Integrar a localização no processo de desenvolvimento"

Para lançar um novo produto, equipes de desenvolvimento tem muitas tarefas de alta prioridade e, geralmente, preferem não ter de se preocupar com a localização até que seja necessário. Como conseqüência, questões localizability muitas vezes são descobertos tarde demais e encontrar o risco de ser adiada para um futuro lançamento. As equipes de produtos nem sempre antecipar o impacto de uma tarefa / recurso específico sobre a localização, e muito frequentemente, a equipe de localização não é capaz de influenciar a concepção ou desenvolvimento até que o recurso já está implementado.

Em um processo ágil, recursos e tarefas de desenvolvimento são controladas em um backlog e revisto no início de cada Sprint. Para eliminar os efeitos colaterais da "throw-over-the-parede" modelo acima descrito, é fundamental para incluir representantes Localização Durante essas reuniões de planejamento de sprint assim mais visibilidade e importância é dada às tarefas de localização. Isso também proporciona grande valor educativo para todos os interessados ​​que podem, então, entender o impacto de suas decisões sobre o processo de localização. Localização ou um proxy também deve participar das reuniões diárias de sprint para acompanhar o ritmo e as decisões de desenvolvimento. Ao participar desses encontros, Membros da equipe de localização pode ser muito mais pró-ativo e influente.

Localization Process Integration

Adobe Revel e Photoshop.com são exemplos de equipes que integram a localização em seu processo de desenvolvimento. Eles também priorizar a localização de recursos intensivos / tarefas iniciais - escultura tempo suficiente para a equipe de localização para executar o seu processo e entregar versões localizadas de alta qualidade.

Num recente Localization World evento, Amrit Singh (Gerente do Programa Internacional para as nossas tecnologias de instalação) presented LocBan (Kanban aplicada à localização). Assim como em uma fábrica da Toyota, a equipe de localização mantém um conselho de "fazer", "Work in Progress" e "Concluído" tarefas que proporciona grande visibilidade sobre a localização "correia transportadora". Similarmente, seria benéfico para manter placas de Kanban para cada tradutor. No modelo em cascata, tradutores usados ​​para receber kits de localização de grandes, que teve que lutar para completar dentro do prazo. No mundo ágil, tradutores são agora capazes de "puxar" o trabalho como sua banda abre.

Localization Kanban

Usando um Kanban bordo integrado, todo mundo tem uma compreensão clara de todas as várias dependências e responsabilidades, resultando em uma maior colaboração e maior taxa de sucesso.

Regra 4 - "Reduzir, Reutilizar e Reciclar "

A localização pode gerar uma grande quantidade de resíduos se não for planejado corretamente. Assim, é fundamental para se tornar "verde" a fim de se tornar mais "ágil".

Reduce, Reuse, Recycle

Reduzir

É claro que a redução do esforço de localização irá ter um impacto positivo sobre a agilidade de um equipa. Isto poderia ser conseguido no 2 maneiras: validando o âmbito localização e reduzindo o desperdício de tradução gerado durante o processo de localização.

  • Reduzir Localização Scope

O trabalho do Gerente de localização é para assegurar que a empresa localiza o produto e conteúdo certo para o conjunto de linguagem certa. No Adobe, tivemos situações em que fomos localizatórios muito conteúdo. Por exemplo, utilização Digital Marketing Suite da Adobe, descobrimos que os clientes russos preferem ler a documentação de Desenvolvimento (tais como descrições API) em Inglês, em vez de em russo. Fomos capazes de guardar um monte de tempo e custo através da remoção deste componente de nossos requisitos de localização.

Similarmente, através de pesquisa de mercado, descobrimos que a maioria dos clientes do Oriente Médio Creative Suite preferem usar uma interface de usuário Inglês com o árabe ou hebraico documentação. Esta combinação torna o conteúdo Inglês como vídeos e tutoriais mais acessíveis para eles.

Em resumo, rastreamento de web analytics e engajamento com os clientes, usuários de energia, testadores de pré-lançamento e GEOS constituem uma ótima maneira de validar os requisitos de localização e melhorar a agilidade.

  • Reduzir o desperdício de Localização

Uma vez que os requisitos de localização são confirmadas, é fundamental para limitar o desperdício gerado durante a tradução do processo de localização. Isso, obviamente, afeta o trabalho dos tradutores, mas também a largura de banda do pessoal para localização.

Sweep Away Waste!Uma forma eficaz de reduzir o desperdício de localização é através da compreensão de sua causa raiz. No Adobe, categorizamos todos os defeitos de localização através de um conjunto de palavras-chave, que nos fornece uma boa imagem dos problemas enfrentados em todos os produtos. Podemos, então, desenvolver soluções para reduzir, se não eliminar, estes defeitos.

Resíduos de localização por vezes origina Inglês Inglês seqüências de assumir é o idioma de origem. De fato, traduções criadas antes de cadeias inglesas ficar finalizado terá de ser revisto e provavelmente vai gerar alguns resíduos.

No mundo ágil, não podemos permitir que o tempo extra, por isso é importante para validar o conteúdo Inglês antes de entregá-lo para os tradutores. Fazer algo tão simples como a verificação ortográfica pode ajudar a reduzir a quantidade de resíduos de localização. Em um produto tal como o InDesign, sobre 3% das seqüências em inglês interface do usuário são atualizadas uma vez que se revista para erros ortográficos e gramaticais. Para um produto que está localizada dentro 25 línguas, isto representa uma perda equivalente a 75% de um único escopo linguagem!

Também, muitas das atividades de análise de localização de software são necessárias porque a localização está acontecendo fora do contexto. Resolver esse problema pode tremendamente acelerar o processo de localização. Em um mundo ideal, localização deve ser uma característica do produto que permite que tradutores para traduzir a interface do usuário no contexto. Facebook fez um ótimo trabalho nesta área, permitindo tradutores (neste caso, a sua comunidade de usuários) para traduzir e fornecer feedback dentro do próprio aplicativo. Alternativamente, tradutores devem ser fornecidas informações de contexto através constrói, imagens ou informações de meta-dados (por exemplo. Comentários desenvolvedor, nome do recurso, tempo de entrega previsto, e assim por diante).

Para reduzir o desperdício, Também é recomendado que os localizadores desenvolver glossários, guias de estilo e ferramentas que aproveitam localizações anteriores.

Finalmente, é fundamental para os tradutores para validar o seu trabalho como eles traduzem. Dessa forma,, actividades para baixo da linha de produção pode ser eliminada ou reduzida, o que torna todo o processo mais ágil.

Reutilizar

Reuse when it makes sense!Reutilizando cordas às vezes pode ser uma fonte de defeitos difíceis em localização de software, por isso tem de ser manuseado com cuidado. Por exemplo, a seqüência de Inglês "none" poderia ser traduzido como "aucun" ou "aucune" em francês baseado no gênero do substantivo a que se refere.

Dito, reutilização de cordas - no mesmo contexto – Também poderia ajudar a melhorar a agilidade, uma vez que estas cordas não precisa ser traduzido várias vezes.

Uma área onde a Adobe tem experimentado resultados positivos com a redução e reutilização de conteúdos em Inglês está em nosso conteúdo instrucional. Na documentação, Adobe depende Acrolinx para controlar a qualidade do Inglês (fonte) conteúdo. Autores precisa usar um certo estilo de autoria (por exemplo. frases curtas) e são incentivados a aproveitar parágrafos existentes (por exemplo. avisos legais). Isto melhora a coerência na documentação Inglês e tem a grande vantagem de reduzir a carga de trabalho muito localização.

Similarmente, DITA (ler Reduzir, Reutilizar e Reciclar: Desenvolver uma estratégia de reutilização para DITA) e Sistemas de Gerenciamento de Conteúdo como Adobe Experience Manager (anteriormente conhecido como Dia CQ) são projetados para reutilização / partilhar conteúdos através de múltiplos canais e publicações.

Reciclar

A reciclagem é o processo de transformação de materiais existentes (ou resíduos) de tal forma que eles podem ser reutilizados - às vezes para uma finalidade totalmente diferente. Criação de lã polar a partir de garrafas plásticas usadas ou isolar paredes usando velhos jeans são exemplos clássicos de reciclagem.

Tais transformações podem ser aplicadas a traduções muito. Tradutores não precisa traduzir cada frase a partir do zero. Tecnologias de tradução, como memórias de tradução e de tradução automática pode ajudar os tradutores reciclar traduções anteriores e acelerar o processo de tradução. No Adobe, temos experimentado ganhos de produtividade dramáticos quando usamos essas tecnologias. Em geral, um tradutor suportado por estas tecnologias vão entregar em uma hora o que outros tradutores iria entregar em um dia. Estes são ganhos expressivos que contribuem para a agilidade localização muito.

Regra 5 – Automatizar, Automatizar, Automatizar

O último requisito para obter a localização ágil é a automação. Com ágil, você não pode dar ao luxo de enviar pedidos de tradução por meio de e-mails ou cortar e colar cordas de uma planilha para um arquivo de origem. Todos tradução hand-offs devem ser automatizados e gerenciados através de um sistema centralizado. Ao longo dos anos, A equipe de Adobe globalização tem desenvolvido como uma plataforma. Este sistema é capaz de se conectar com vários sistemas de controle de origem, gerenciar os trabalhos de tradução, alavancar traduções existentes entre os projetos e tipos de conteúdo e fornecer mecanismos de tradução automática. Na tab Mito globalização 4 artigo, Guta Ribeiro introduziu Aeroporto, nosso novo sistema para se conectar automaticamente com os nossos fornecedores e nos ajudar a marcha em direção ao nosso sublime de uma hora objetivo tradução.

Automate

Além da tradução, também é importante para automatizar outros aspectos do processo de localização, como construir, garantia de qualidade, correção de bugs, screenshots e distribuição das versões localizadas. Nós só podemos ir tão rápido quanto o nosso componente mais lento, é por isso que é fundamental para automatizar todos os aspectos do processo de localização.

Conclusão

Agilidade localização pode ser alcançado, desde que todas as partes interessadas trabalhar como uma equipe unificada. É fundamental para os engenheiros do núcleo para desenvolver um código bem internacionalizado a partir do get-go. Isto pode ser conseguido através da formação, revisões de código, utilização de (Open Source) bibliotecas de internacionalização e globalização boletins.

O processo de localização devem ser plenamente integrados no processo de desenvolvimento global para que todas as dependências e responsabilidades são claras. Recomendamos o uso de placas de Kanban (através de ferramentas como o Trello) para aumentar essa visibilidade. Para se tornar ágil, também é importante para agir "verde" (I.E. reduzir, reutilizar e reciclar). Isso representa uma maneira eficaz de controlar a produção de resíduos, antes e durante o processo de localização. Finalmente, todos os esforços devem ser feitos para automatizar todas as partes do processo de localização simplificada.

No Adobe, nem todos os projetos de localização são tratados com grande agilidade - ainda! Alguns projetos são mais ágeis do que os outros. Contudo, com base em nossa experiência, acreditamos que a agilidade pode ser alcançado com a adoção destas Cinco Regras de Ouro:

  1. "Nós somos uma equipe!"
  2. "A internacionalização é rei"
  3. "Integrar a localização no processo de desenvolvimento"
  4. "Reduzir, Reutilizar e Reciclar "
  5. "Automatizar, Automatizar, Automatizar "

 

Um agradecimento especial a Rob Jaworski, Amrit Singh Pal, Ashish Saxena, Janice Campbell, Leandro Reis, Peter Green, Julia Feng e Quynn Le pela sua inestimável feedback sobre este artigo.