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.

Multilingual conteúdo resumo da reunião de Inteligência SIG

O conteúdo multilíngüe terceiro meetup grupo de interesse especial é de cerca de AEM multilingue DAM. Cerca de metade da comunidade implementadas AEM DAM. Mas DAM é um tema popular em que as pessoas já estão perguntando sobre as melhores práticas em torno de organizar, localizar e procurar ativos globais. Portanto, este SIG está se preparando para enfrentar a necessidade para aqueles que querem saber por que DAM é necessário e como outras pessoas estão usando-o, bem como para aqueles que implementou DAM, mas não tenho certeza se a forma como eles usá-lo é a melhor maneira. Ele também acabou por ser muito útil para os nossos parceiros de tecnologia que estão olhando para casos de uso do cliente para desenvolver conectores DAM. AEM clientes da Intel, Xlinx, SAP, SuccessFactors, Instituto Sas, Paypal participou, juntamente com parceiros de Cloudwords, TDC, ClayTablet, etc.

A reunião começou com um panorama da AEM DAM dada pelo Sr gerente de marketing de produto Elliot Sedegah. Foi uma sessão muito informativa e interativa, com muitas demos. Ele demoed alguns dos AEM5.6.1 e 6.0 características, tais como o fluxo de trabalho de colaboração entre profissionais criativos e gerente de marketing colaborando em revisão de ativos, fazer upload, etc. Ele também mostrou o novo recurso de integração Scene7 DAM na renderização de texto dinâmico em uma imagem. Muito interessante. Nick da Adobe.com depois mostrou um POC na localização de ativos usando este recurso OOTB. Elliot também mostraram ativos Compartilhar que é como uma espécie de portal para busca de ativos e fazer o download. Este segways em um tópico que muitos participantes estão interessados ​​em SIG - qual é a melhor prática de organizar os ativos DAM. Muitos deles usam pastas. Elliot mencionado tanto o uso de pastas e uso de metadados. A vantagem do uso de metadados é que ele é parte do ativo, independentemente de onde é. Também é ótimo para pesquisa. A maioria desses demos estão na interface do usuário otimizada para toque, o que é muito legal olhar.

Em seguida, Web Marketing Sr. Gerente Gary Gamitian da SuccessFactors apresentou seu caso de uso DAM em SuccessFactors.com. Eles lançaram CQ5.5 dezembro passado e até agora tem locais vários idioma / localidade. Gary nos mostrou seu site Centro de Recursos. Ele usa tanto tagging e metadados impulsionado busca de seus ativos digitais. Eles têm regras muito rígidas sobre reforço de metadados. Uma coisa que ele mencionou o que seria um recurso útil é a funcionalidade de cópia idioma para ativos DAM. Isso automatizar população imobilizado adquirido.

A sessão da tarde é em torno de localização de ativos. Sr. Produção Web Manager Nick apresentado como Adobe.com vai alavancar o novo recurso Scene7 para localização de ativos. Basicamente, a integração permite selecionar um ativo diretamente do repositório Scene7 através AEM. A camada de texto na imagem é parametrizado de modo que você pode mudar o texto diretamente no componente site on the fly, ou empacotá-lo como conteúdo traduzível para enviar para um sistema de gestão de Tradução. Sara Lockhart-Sirman, Operações Web Manager at Intel também mostram encaixotado como eles estão usando o componente AEM personalizado para localizar texto em uma imagem no CQ 5.4.

Finalmente, Sr. Diretor de produção Cedric Huesler e Sr. Tradução Technology Group Gerente Chris Duran deu uma atualização sobre as questões HSH esta comunidade relataram. Eu vi alguns rostos felizes na sala em um presente.

Grandes sessões gerais, eo refresco é incrível também!

Niu Mengmeng

Multilingual Program Manager conteúdo

Compartilhando cursos de eLearning localizadas em toda a mídia social via Adobe Captivate

Adobe Captivate é uma ferramenta de aprendizagem electrónico que pode ser usado para demonstrações de software autor, simulações de software, e randomizados testes em swf e formato HTML que podem ser convertidos e enviados para sites de hospedagem de vídeo. Este conteúdo pode ser compartilhado através do Facebook e Twitter para fazer eLearning uma tarefa muito simples e interessante. Adobe Captivate é enviado em 7 local - Inglês, Francês, Alemão, Japonês, Espanhol, Coreano e Português mas os cursos e demonstrações podem ser criados em outras línguas também e podemos compartilhar esses cursos localizados muito facilmente. Conseguir um conteúdo on-line em língua nativa define os alunos livres de sua dependência em Inglês locale.

Criação de cursos de eLearning localizadas

Abaixo guia de passos que como é simples de compartilhar suas criações de alta qualidade e demonstrações no YouTube e ainda através do Twitter / Facebook via Adobe Captivate 7 mesmo sem ter muito conhecimento prévio do produto. Ele também irá destacar algumas das questões triviais, mas importante, que pode impedir que os usuários compartilhem conteúdo em Inglês, bem como localidades não-inglês. Esta solução pode ser útil para muitos criadores de conteúdo nativas.

1. Lançamento Captivate e selecione Vídeo de demonstração ou Software de Simulação de Arranque página. Software de simulação registra eventos como clique do mouse, entrada de teclado, e eventos do sistema e criar slides de acordo. Vídeo de demonstração permite criar um único vídeo que pode ser publicado diretamente para o arquivo mp4.

111

2. Selecione o aplicativo ou área da tela que você quer demonstrar e selecionar predefinições padrão para iDevices(iphone, ipad), YouTube ou personalizá-lo conforme exigência. Selecione o modo panorâmico para focar áreas de tela manualmente / automaticamente com o movimento do mouse.

2

3. Selecione o botão "Configurações" e vá em Preferências Globais. E selecione o idioma no qual você deseja gerar as legendas. As legendas são gerados automaticamente em caso de simulações de software que ajudam na orientação ao longo da formação. Captivate permite a criação de legendas em vários locais na lista. Eles podem ser editados manualmente, se necessário.

3

11 As legendas podem ser gerados em qualquer um dos idiomas selecionados pelo usuário.

4. Adicionar narração em áudio para a sua demonstração através da selecção do dispositivo de entrada de áudio do. Sistema de áudio podem ser adicionados, bem como para os projetos junto com a narração.

4

5. Depois de todas as configurações, clique botão de gravação. Adicionar narração e manter demonstrando seu projeto. Depois de ícone da bandeja conclusão bater END ou clique na barra de tarefas do sistema.

6. O vídeo é reproduzido antes de você e não há opção de editá-lo, mas se ele está devidamente registrado basta clicar em "YouTube". Clique no ícone de pasta para publicá-lo localmente como um arquivo mp4. (Isso pode ser compartilhado como um arquivo independente, bem) . Você pode ajustar a relação de aspecto, qualidade, FPS neste fluxo de trabalho. Mesmo depois de receber uma loja de cópia em sua máquina cativar pergunta sobre YouTube publicar bem.

5

6

Modo de Edição: Se o vídeo precisa de alguma correção clique em "Editar" e modificar o vídeo. Corte de vídeo adicional, zoom em áreas importantes, desdobramento de vídeo em duas partes, inserir objetos, inserir outro PIP (picture in picture) vídeo é possível no modo de edição.

Cursos de partilha no YouTube, Facebook & Twitter

1. Publicar no YouTube:

Se você já tiver uma conta do YouTube, introduzir as suas credenciais e aceitar o contrato de licença e fazer login no YouTube.

Para novos usuários sem conta YouTube, clique sobre o novo usuário e você será redirecionado para página de inscrição para o Google. Crie sua conta e após a criação bem sucedida voltar logo para o Adobe Vídeo Editor e inserir os seus dados. Muitas vezes os usuários enfrentam um problema que, mesmo após a criação bem-sucedida de conta que eles não são capazes de se identificar e enfrentar um erro que o nome de usuário / senha especificada incorreta embora no YouTube que pode logar com as mesmas credenciais.

7

8

A questão é que cada nova conta no YouTube precisa de verificação. Sem conta que está sendo verificado que você não pode fazer o upload do seu vídeo. Para verificar a conta você pode criar seu canal do YouTube ou verificar através de seu telefone.(Isso se aplica a Adobe criador Video Presenter bem)

Depois de ter logado adicionar uma descrição para o seu vídeo e marcá-lo na categoria adequada público / privado e UPLOAD! Você pode ver mais longe você vídeo no YouTube ou copiar link para compartilhar com os colegas.

2. Publicar no Facebook e Twitter

Para compartilhar o curso on Facebook / twitter verificar respectivos botões e POST.

9

Às vezes usuário pode enfrentar um diálogo em branco ou uma caixa de diálogo dizendo que ocorreu um erro interno quando eles postam vídeo no Twitter ea questão não é facilmente isolado. Mesmo reiniciar / republicar não leva a qualquer sucesso.

10

A razão por trás disso é uma questão oAuth. Temos de garantir que data e hora do sistema está em sincronia com o Twitter do. Twitter retorna o tempo atual na “Data” Cabeçalho HTTP com cada solicitação. Se o seu pedido não devido a uma incompatibilidade de data e hora, usar esse tempo para determinar o delta entre o relógio do sistema e seu relógio do servidor e ajustar seus selos oAuth_time para solicitações subseqüentes de acordo. Então tudo que você precisa fazer é verificar que a hora do sistema é definido mesmo que por fuso horário correto e você não tiver modificado. Para, por exemplo. Se o fuso horário é (EUA e Canadá) Hora do Leste, em seguida, seu tempo de sistema deve ser o mesmo como o tempo atual de que a região só mais o twitter não vai voltar seu pedido. E você vai ter erro interno. Esse problema pode ocorrer com pessoas que seguem diferentes localidades que podem definir sua zona para outra região e hora do sistema para sua própria região. Pode referir-se https://dev.twitter.com/discussions/204 para mais detalhes.

(Também aplicável ao criador de vídeo Adobe apresentador.)

Ao seguir os passos acima, os alunos agora podem usar suas próprias contas no Facebook / Twitter para saber mais por se matricular nestes cursos. Vai ser uma grande experiência para aprender através de portais de redes sociais . Então comece a gravar e compartilhar seus projetos em Adobe Captivate e compartilhá-los em todo o mundo para se conectar com mais e mais pessoas e incentivar eLearning – a prática de aprendizagem mais rápida e eficiente.

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.

O problema com Software Localizando para múltiplas plataformas

Adobe tem uma longa história de desenvolvimento de produtos para múltiplas plataformas, quer se trate de aplicações de desktop como nossos aplicativos Creative Suite emblemáticos ou aplicações sensíveis ao toque mais recentes, como Photoshop Toque. A maioria dos nossos aplicativos de desktop foram construídos para Windows e Mac e aplicações mais recentes continuar esta tendência, com suporte para iOS e Android, incluindo tablet e telefone fatores de forma para ambos.

Claro que isso não teria sido possível sem os esforços cuidadosos da equipe de engenharia para manter em grande parte uma única base de código para todas as plataformas.

Apesar de ter uma única base de código tem benefícios óbvios, na camada de interface do usuário muitas vezes é importante ter variações de plataformas específicas para uma melhor usabilidade. Cada plataforma tem geralmente uma convenção específica para se referir ao sistema de menus, teclas de atalho e elementos de interface do usuário. Por exemplo, em uma plataforma Windows uma String UI pode ser – “Selecione um arquivo de mídia através do botão Procurar ou digite um caminho válido.” ea mesma seqüência para a plataforma do Mac pode ser – “Selecione um arquivo de mídia através do botão Escolher ou digite um caminho válido.”

Isso significa que as cordas UI traduzíveis pode ter muitas variações no idioma de origem, dependendo de qual plataforma eles são destinados a. Isto é o que o nosso grupo de globalização geralmente se refere como "Plataforma de variância’. Cordas localizáveis ​​são essencialmente múltiplo entidades. Cada corda localizável tem um identificador e múltiplos valores associados cada um dos quais podem ser selecionados com base em determinados critérios. Os critérios mais óbvios e comumente utilizado é o idioma da interface do usuário do aplicativo, mas ele não precisa ser o único. Plataforma também pode decidir o valor de uma string.

Suporte de variação plataforma não é apenas útil para o tratamento de diferenças de terminologia para se referir a elementos de interface do usuário do sistema, ele também ajuda a adaptar cordas para diferentes tamanhos de tela. Aplicação moderna são projetados para suportar vários formatos de dispositivos como tablet e telefone com a interface do usuário que está sendo ajustado para cada plataforma para uma melhor experiência do usuário. Variância plataforma, neste caso, pode ser usado para apoiar cadeias mais longas para a vista Tablet e cordas mais curtas para a exibição do telefone.

No entanto, outra área onde o suporte de variação plataforma poderia ser útil é em ter diferentes valores localizáveis ​​para uma versão Pro versus uma versão do Consumidor da aplicação.

Contudo, localizar strings com dados variante da plataforma é um problema. O problema é duas vezes, é na gestão dos processos e cronograma do projeto para permitir a localização ágil e lançamento simultâneo para todas as plataformas-alvo. O segundo aspecto é tecnicamente apoiar a variância plataforma em ambas as bibliotecas de programação e ferramentas de tradução. Muitas ferramentas e bibliotecas de assumir um único valor para uma origem e uma seqüência alvo, mas no caso da plataforma de variância não só pode haver múltiplas fontes e os valores de alvo para uma cadeia lá não necessita de ser de um-para-um entre os valores de origem e de destino. Pode haver múltiplas variantes de plataforma para a cadeia de origem que são mapeados para o mesmo valor / target traduzido ou uma única seqüência de origem pode precisam ser traduzidos de forma diferente com base na plataforma para o local de destino. Por exemplo:

  • pt_BR: “Por favor, feche a janela e começar de novo.”
  • fr_FR padrão: “Feche o diálogo e tente novamente.”
  • O Windows fr_FR: “Feche o diálogo e tente novamente.”

Desde que eu sou parte da equipe de ferramentas de globalização aqui no Adobe, o restante deste post eu descrever o problema mais de uma ferramentas técnicas e perspectivas bibliotecas, desenho da minha experiência. O problema processo também é bastante complexo e, provavelmente, ter um post muito mais tempo blog para discutir. Na verdade, há um um relacionado já neste blog, ver – link.

Suporte Variance plataforma em Bibliotecas

Idealmente, as bibliotecas de globalização / APIs usadas no código para gerenciar cadeias externalizados e os formatos de armazenamento correspondentes para os dados externalizados deve ter uma noção de um valor variante plataforma para cada corda. Deve haver uma maneira de pedir um valor de string para uma localidade e uma plataforma específica, juntamente com uma disposição para voltar a cair para um valor padrão no caso de um valor específico da plataforma não é especificado.

Como um exemplo, a API Java ResourceBundle suporta a seleção de um pacote de 'Locale', não há menção explícita de uma "Plataforma", mas o 'Locale’ si é extensível para suportar variantes. O mecanismo de variante no 'Local’ pode ser usado para suportar plataformas diferentes, e existe também um mecanismo de queda para trás. No Adobe temos uma biblioteca multi-plataforma desenvolvido personalizado chamado ZString para o gerenciamento de cadeias de externalizados com apoio explícito para a plataforma de variância.

Suporte Variance plataforma em Ferramentas de Tradução

A maioria dos sistemas de gerenciamento de tradução (TMSS) ter um one-to-one modelo de strings com as cordas correspondentes traduzidos para cada localidade. Este pressuposto está por trás da arquitetura dos algoritmos correspondentes TM, bem como o desenho da bancada tradução. Um típico bancada tradução normalmente oferece um lado a vista lateral de origem e de destino cordas, mas apenas apoiar uma única seqüência de fonte correspondente a um valor único traduzido.

Typical Translation Workbench

Um lado típico de visão lateral de origem e conteúdo alvo de uma ferramenta de tradução

Nós ainda estamos procurando a solução ideal para este problema. Para gerenciar os TMs uma possível solução usando os sistemas existentes é ter entradas duplicadas na memória de tradução (TM) ou um TM separado para cada plataforma.

Contudo, tradutores ainda são limitados pela visão apresentada pela sua bancada de trabalho de tradução. Uma possível solução para permitir que os fornecedores de tradução para fornecer a plataforma traduções específicas é duplicar todas as cordas de origem para cada plataforma alvo possível. O valor de origem para o padrão da plataforma pode ser usado como valor de fonte para todas as outras, a menos que a plataforma de aplicação UI já especifica um valor para uma plataforma específica, caso em que é usado. Agora, o tradutor pode fornecer traduções diferentes para cada plataforma, se necessário. Essa solução no entanto parece ser uma quantidade significativa de trabalho adicional para os tradutores. Alguns otimização é possível traduzir uma única plataforma primeiro e aproveitando traduções para todas as outras plataformas.

Em um cenário ideal da bancada tradução daria um lado a vista lateral de todas as variantes de plataforma para a string de origem e as cordas alvo. Com a capacidade para o tradutor para remover as variantes da seqüência traduzida onde eles não são necessários e propor variantes para a cadeia traduzido mesmo se a seqüência de origem não tem qualquer. Isso permitiria que os tradutores a trabalhar com o conteúdo de origem em uma única passagem, edição de traduções alavancados, proporcionando novas traduções quando necessário e propondo valores traduzidos específicos da plataforma, conforme apropriado.

Uma aproximação com esta visão ideal é uma folha de Excel com cada corda fonte que está sendo representado em uma linha e ter uma coluna separada para cada plataforma, tanto para fonte e cordas alvo. Com os valores em branco numa coluna plataforma significando que o padrão de tradução é para ser usado para essa plataforma e entradas da plataforma não em branco a ser utilizado para a plataforma de tradução específicos.

Ideal Translation Workbench

A proposta vista bancada tradução permitindo traduções simultâneas para múltiplas plataformas

Nós ainda estamos experimentando para encontrar a solução ideal para as nossas necessidades, que oferece flexibilidade para tradutores e ainda aproveita o nosso investimento em processos e ferramentas de tradução existentes. O objetivo é ser capaz de suportar mais rápido ciclos de lançamento ágeis com todas as versões da plataforma acontecendo simultaneamente.

Acho que este é um bom fórum para pedir aos nossos leitores do blog, se enfrentaram problemas semelhantes e as soluções que desenvolvemos para lidar com ele.

Localização de marketing da Adobe - que funciona, o que é um desafio

Pediram-me, recentemente, para conversar com um casal de colegas da indústria sobre a localização de Marketing da Adobe e pensei que iria fazer um post de blog interessante também.

No Adobe, Localização Marketing é centralizado e consiste em uma equipe de Gerentes de Programas Internacionais, que eu consigo.

Eu acredito que este ainda é o modelo certo para nós. Adobe tem escritórios em todo o mundo e descentralizar a localização de marketing que realmente introduzir ineficiências. Dito, o desafio com um modelo centralizado é equilibrar a produtividade com a capacidade de fornecer GEOs com o processo e as ferramentas adequadas para que eles possam participar e dar um valioso contributo ao redor nuances específicas de GEO, conteúdo específico do país, etc. Este é um desafio on-going e nós trabalhamos muito estreitamente com os nossos gerentes de marketing em todo o mundo para conquistá-la.

O desafio aqui é o equilíbrio entre dar mais flexibilidade e liberdade de expressão para as regiões eo uso de ferramentas de produtividade, como a memória de tradução. Se quisermos aproveitar as economias que TMs e outras ferramentas para oferecer localização (e fazemos), nós podemos oferecer alguma flexibilidade no conteúdo do destino, mas não tanto quanto, por vezes, as regiões gostaria de ter - por exemplo, completa re-escreve de segmentos.

No Adobe estamos cientes destas questões ea chave aqui é trabalhar em estreita colaboração com os escritórios regionais e oferecer-lhes a oportunidade de fornecer feedback cedo, diretamente para o conteúdo da fonte, antes de localização começa. Também significa proporcionar oportunidade para comentários sobre o conteúdo localizada que são apresentados no contexto de um processo que permite feedback fácil. Nosso GEOs são gerentes de marketing de campo e somos sensíveis à quantidade de tempo gasto em comentários.

Desafios

Há sempre desafios em localização e em particular na localização de Marketing, onde "boa tradução" não é apenas bom o suficiente.

Leve o Marketing Digital BU por exemplo. Campanhas em todo o mundo em torno das soluções de marketing digital tem que apelar para 'marketing', para os profissionais que criam conteúdo de marketing, e assim o 'bar qualidade localização "para o conteúdo que oferecemos a nossa GEOs foi levantada significativamente.

Aqui está um exemplo de uma campanha recente que foi particularmente desafiador para a localização, devido ao uso da mesma expressão centrada EUA "carrapatos-los". Para tradutores nem sempre é uma escolha clara de palavras para a língua-alvo. O "peso" de expressão e o que ela transmite necessidade de ser tomado em consideração.

12

Os escritórios regionais são livres para criar seus próprios materiais de marketing - Orientações de marcas internacionais estão no local ea equipe de Adobe Marca trabalha diretamente com o GEOs para garantir uma interpretação coerente e uma utilização da nossa marca.

Estamos muito protetor quando se trata da marca Adobe, e embora os escritórios regionais são dadas alguma flexibilidade em termos de criação de alguns dos seus próprios materiais de marketing (na sua língua original), A equipe de Adobe Marca normalmente está envolvido para garantir que os materiais seguem as diretrizes de marcas internacionais estabelecidas.

Que regiões ou mercados internacionais são mais difíceis e desafiadoras para a localização?

Eu acho que qualquer um que trabalha na localização seria começar por dizer que o japonês é uma língua muito difícil de localizar. A idéia de "tradução" já é algo que não é apreciada pelo mercado japonês. A "tradução" muito bom ainda significa 'é traduzido' e por isso tem um fluxo diferente e sentir que o conteúdo que é originado em japonês. Isso se torna um desafio ainda maior em torno do conteúdo de marketing.

No Adobe temos um programa bem-sucedido para a localização de campanhas de marketing em japonês e que envolve o trabalho em estreita colaboração com nossos gerentes de marketing de produtos no país e emprega editores de texto no país quando necessário.

Dito, todas as línguas e todos os países apresentam desafios. Nós recentemente teve que lidar com as mudanças ortográficas em Português do Brasil, alterações de tonalidade em espanhol (formal para um tom mais informal), questões de imagens no Oriente Médio, diferentes "sabores" de uma única língua, e assim por diante. Eu acho que eu diria que não existem regiões "fáceis". Nosso trabalho é sempre interessante e olhamos para esses desafios com uma atitude muito positiva - estes desafios são o que diferenciam tradução de localização e é sempre emocionante fazer parte deste processo, onde você vê as mensagens fonte implantado em todo o mundo e tendo o impacto desejado apropriado em cada região, em todo o mundo.

Que aspectos da marca são mais importantes para localizar para audiências regionais? Quais os canais são mais importantes?

A ênfase tem muito deslocado para conteúdo on-line (páginas da web, conteúdo multimídia e social), a maior parte do conteúdo que agora localizar vai acabar em Adobe de 57 site. A necessidade de conteúdo impresso diminuiu, mas existem ainda algumas regiões que precisam de ser fornecido com o conteúdo impresso. Tentamos ouvir a nossa GEOs e fornecer materiais localizados relevantes.

'Look and feel' A Adobe é muito homogênea em todos os nossos sites. Nossos escritórios regionais têm a flexibilidade para adicionar conteúdo específico do país, mas o modelo de site é o mesmo para todas as localidades e todos os sites internacionais são gerenciadas centralmente.

Os escritórios regionais também são livres para criar alguns dos seus próprios materiais de marketing - Orientações de marcas internacionais estão no local ea equipe de Adobe Marca trabalha diretamente com o GEOs para garantir uma interpretação coerente e uma utilização da nossa marca.

Acredito que o grande desafio agora é a criação de uma forte e bem-sucedida marca criativa Nuvem todo o mundo - e estamos bem encaminhados :-)

Ponto de partida

Os escritórios regionais deve ser uma extensão da sua equipe e levadas em consideração em todas as etapas de seus processos e ferramentas.

 

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

Pronto para a comunidade: Adobe Centro de Tradução (ATC)

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

Um único gateway em Tradução da Adobe Comunidade “universo”

Novembro 2012 marca o mês quando o grupo de Globalização da Adobe está lançando o “Adobe Centro de Tradução” (ATC) em translate.adobe.com. Para os clientes da Adobe e fãs, ATC será o único ponto de acesso para fornecer idéias, feedback e melhoria de traduções existentes em “Línguas Adobe”, as línguas de expedição de um produto da Adobe. Ao mesmo tempo, O centro também vai ser o lugar onde a nossa comunidade de tradutores vibrante e crescente explora – de forma colaborativa – oportunidades para “línguas da comunidade”: Idiomas que estão em alta demanda por seus falantes, mas não entregues como parte de nossas ofertas de produtos.

ATC Landing Page

ATC página de destino

Até agora, nossa tradução comunidade “universo” consiste de dois planetas, refletindo seus atuais dois focos principais:
Adobe Centro de Tradução
em si está agora oferecendo funcionalidades permitindo que os fãs para colaborar em interface com o usuário (UI) tradução (anteriormente esta tem estado disponível através Tradutor Adobe). A atividade em torno de tradução da interface do usuário vem crescendo rapidamente, suportado e usado por várias centenas de contribuintes.
O Adobe Tradução Comunidade TV projeto é gêmeo muito sucesso ATC maior: Mais do que 2,500 tradutores já traduzido para mais de legendas 14,000 minutos de vídeo para fazer educação, divertido, e conteúdo útil disponível num número crescente de idiomas.

Não muito tempo atrás …

Em Novembro 2011, este blog apresentou o caso de sucesso de como os fãs e usuários habilitados Adobe Business Catalyst (BC) de navio com uma interface de idioma adicional em holandês, inteiramente traduzido pela comunidade de parceiros BC. A motivação desse esforço foi o interesse para melhor servir os parceiros’ clientes em que a linguagem (BC com o holandês UI).

Desde então, a equipe de produto ATC tem sido ocupado no trabalho e colocar um esforço significativo para melhorar a tradução do Centro “olhar & sentir” e sua funcionalidade. Entrando comentários e sugestões de tradução é agora possível de forma intuitiva e com uma interface visualmente agradável que segue a experiência geral Adobe.com. Tal como acontece com todos os produtos Adobe, metodologias ágeis de desenvolvimento estão permitindo que a equipe reagir ao feedback do usuário: Mesmo que ATC é então lançado, ainda consideram que é “trabalho em andamento” (ao contrário de “em pedra”) e estão ansiosos para ouvir o que a comunidade deseja, a fim de ser mais produtivo ou para ter uma experiência mais agradável tradução colaborativa.

Product Explorer

Produto Explorador

“Tradução comunidade” da Adobe

No Adobe, Tradução comunidade se refere ao processo de permitir que nossos usuários para traduzir o conteúdo em um ambiente colaborativo, assistida por tradutores profissionais ou moderadores. Tipos de conteúdo disponíveis para tradução comunidade hoje são vídeos (através do Adobe TV) e interface de usuário do software (através da funcionalidade no Adobe Centro de Tradução). No futuro, esperamos tradução comunidade para expandir em áreas como fóruns de documentação ou de usuário.
Idealmente, colaboração e interação entre contribuintes devem fazer comunidade de tradução de uma experiência gratificante e divertido. Estamos confiantes de que nossas ferramentas contribuirão para uma experiência, para que as comunidades vivas e apaixonado irá desenvolver e prosperar em torno deles.

Por que a Adobe promover tradução comunidade?

Adobe tem uma longa história relacionada à localização e globalização. Nossos produtos estão atingindo pessoas de todo o mundo e permitir-lhes para expressar sua criatividade, independentemente da sua língua nativa ou os locais onde elas vivem e trabalham. Não importa o idioma que estamos usando, quando se fala de nossos usuários, estamos sempre profundamente impressionado, quão importante os nossos produtos são para eles e com quanta paixão falam deles.
Em seu núcleo, Adobe é uma empresa tão internacional como nossos usuários. Temos escritórios em todo o mundo, e em todas as nossas equipes um mundial encontra colegas de todo o mundo de: O desejo de servir a todos os nossos clientes internacionais com excelência, é profundamente enraizado em nós mesmos e é refletido em nosso trabalho diário.

Programa da Adobe tradução comunidade é um meio de obter mais um passo para o objetivo de enviar "mundo pronto" ou "verdadeiramente global" produtos da Adobe, com base na demanda expressa e dados fornecidos por nossos clientes e comunidades de usuários ao redor do mundo.

Lightroom Polish

Lightroom polonês projeto

Por que a Adobe está a construção do Centro de Tradução Adobe?

No passado, Adobe pioneiro de um programas de tradução poucos comunidade, resultando em ótimas respostas de nossos usuários. Após uma série de pilotos, agora estamos começando a unificar todos os esforços de tradução da comunidade da Adobe em um único lugar: Adobe Centro de Tradução (ATC).
Com engenheiros, experiência designers de usuário, e gerentes de produto, ATC tem uma equipe dedicada produto cujo objetivo é fornecer a melhor experiência para os tradutores de diferentes comunidades. Construção e manutenção de uma plataforma que representa um grande investimento para o Adobe. Contudo, acreditamos que o ganho de longo prazo resultantes de uma melhor compreensão dos nossos usuários internacionais, vai valer a pena o esforço, tempo, e investimento.

Benefícios da tradução comunidade

A cooperação entre a Adobe e seus confiáveis ​​tradutores profissionais tem trabalhado muito bem por muitos anos agora. Este esforço conjunto vai continuar a ser uma pedra angular do sucesso internacional da Adobe. Contudo, existem alguns aspectos da tradução produto onde o envolvimento da comunidade de usuários pode ter vantagens sobre os fluxos de trabalho tradicionais ou pode levar a algo completamente novo.

Feedback e traduções através de pessoas que usam nossos produtos todos os dias

É impossível para tradutores profissionais para ser especialistas para todos os produtos ou áreas que estão traduzindo para. Embora o trabalho dos profissionais, com certeza será sempre correta, o usuário do produto todos os dias pode - de vez em quando - tem uma vantagem de fornecer up-to-date traduções.
No passado, temos experimentado que algumas traduções em nossos produtos não refletem o uso predominante de termos pelos nossos clientes. Nesta área, queremos aproveitar a oportunidade para fazer nossas traduções corresponder às necessidades de nossos usuários e expectativas. Com intenção semelhante, estamos alavancando mecanismos como votação da comunidade ou comentando, de modo que as traduções corresponder as expectativas da comunidade em geral e não estamos representando comentário isolado.

É importante notar que não haverá “forma automática” para uma tradução comunidade para entrar no produto final com a revisão: A fim de manter a qualidade dos nossos produtos são conhecidos pela, sempre haverá moderadores de confiança e revisores perto da comunidade que fazem a decisão que a corda está pronto para inclusão no produto final. A propósito, apenas com a ajuda de nossos parceiros do lado de tradução profissional, vontade vamos ser capazes de alcançar escalabilidade e suporte para as línguas comunitárias numerosas.

Avaliação de mais idiomas produtos Adobe

ATC Lightroom

ATC Lightroom Página

Historicamente, Adobe tem enviado em idiomas que foram representando nossos principais mercados: América do Norte, Europa, Japão, Ásia. Isso é um bom número de línguas já. Agora com todo o planeta como o potencial de mercado local para os nossos produtos, contudo, estamos constantemente a enfrentar a questão que idiomas para enviar os nossos produtos em. Atualmente, não é possível traduzir em todas as línguas do mundo, devido à logística, custar, e informações incompletas sobre o tamanho do mercado endereçável.
É exatamente a pergunta que língua a tomar na próxima, onde a tradução comunidade vai ajudar a encontrar uma resposta, invertendo um mecanismo comum: Em vez de ter que fazer suposições sobre tamanhos de mercado e demanda por produtos traduzidos antes de enviá-los, ATC é capacitar os nossos usuários para indicar que as línguas são importantes para eles e, por isso, nos: Tamanho da comunidade filiação e velocidade de translação para uma linguagem de produto, serão indicadores cruciais.

Línguas de produtos de transporte vs. candidatos para novos idiomas

Existem dois diferentes grupos de línguas que estamos disponibilizando para a tradução comunidade:

“Línguas Adobe” são todas as línguas que são o transporte de corrente dentro de um produto. Para “Línguas Adobe”, os usuários podem fornecer traduções alternativas se descobrirem erros tipográficos, se uma cadeia é muito longa ou cortada, ou simplesmente, se eles preferem uma tradução diferente sobre o que está aparecendo no produto. Em nossas ferramentas, línguas transporte geralmente aparecem como 100% traduzido e revisado em nossas ferramentas. Não obstante, Adobe está ansioso para a comunidade proporcionando-nos um feedback para esses idiomas.

“Línguas comunitárias” não lançado com um determinado produto e nós temos torná-los disponíveis para tradução comunidade. Para esses idiomas, pode haver diferentes razões pelas quais estamos adicionando-os ao ATC: Uma comunidade de usuários apaixonados que se tem conhecimento em um determinado país, ou repetidas solicitações do usuário para ter um produto disponível em sua língua, ou por motivos de negócios no lado Adobe.

Divulgação completa: Para ser perfeitamente claro, um “língua da comunidade” que é 100 por cento traduzido por uma comunidade apaixonada não será automaticamente o transporte com uma versão futura do produto. A decisão de negócios que as línguas de navio, será da responsabilidade exclusiva dos produtos’ partes interessadas. Tanto a comunidade e Tradução Adobe equipe do Centro terá sempre a adiar a decisão final para a equipe de produto.

Por que os usuários se envolver em tradução comunidade?

Lightroom Translation

Lightroom Tradução

Usuários que participam na tradução da Adobe programa comunitário de ter uma chance de se envolver no desenvolvimento de suas ferramentas favoritas. Eles podem afetar diretamente a tradução de um produto através de sugestões apresentação.
E mesmo se a tradução para uma língua específica já foi concluído, usuários continuarão a ter um canal para expressar sua opinião (sobre a qualidade da tradução). Ou eles podem nos ajudar a melhorar o produto através de relato de bugs de localização em uma interface conveniente, sem a necessidade de passar por sistemas de relatórios complexos de bugs.

Ao aderir ao programa Adobe tradução comunidade, usuários vão reforçar o papel da sua comunidade local e impacto. Em troca, eles vão receber mais atenção. e, além disso, eles têm uma boa chance de influenciar o futuro de um produto da Adobe, talvez até além do apoio de localização.

Tradução comunidade já é uma forma comum para muitas empresas (Colegas da Adobe sobre a indústria de software entre eles) para explorar novas formas de interagir e se envolver com os fãs, usuários, e os clientes. Para Adobe, que tipo de interação é uma forma de melhor ouvir a voz de nossos clientes.

Nós acreditamos fortemente que nossos produtos vão continuar a melhorar, porque temos a intenção de escutar essa voz …

Por favor, visite (e “como”) nosso Página do Facebook ou começar a seguir-nos no Twitter.

 

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

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)