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.

Usando fontes do sistema em aplicações baseadas em Flex

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

Ao trabalhar com aplicações baseadas em Flash, há problemas com fontes desde as fontes especificadas não podem existir na máquina do usuário. O problema é agravado quando se tem usuários internacionais cada um dos quais pode estar trabalhando em vários sistemas operacionais (Windows, Mac), versões múltiplas (Win XP, Win7, Win8, Mac 10.6, e Mac 10.7), várias localidades (Francês, Italiano, Espanhol, Etc russo) e, portanto, a existência de diferentes fontes disponíveis do sistema. Uma opção para agilizar a experiência seria incorporar fontes - fontes inteiras ou um subconjunto específico de caracteres de uma fonte. A outra opção seria a utilização de fontes do sistema operacional padrão.

Instalador da Adobe e licenciamento componentes (que sai com Master Collection e quase todos os produtos pontuais como o Photoshop, InDesign, e Illustrator) usa a abordagem mais tarde. O componente identifica a localidade do usuário do sistema operacional de localidade e, em seguida, pega uma fonte de uma lista de prioridades de pré-definida lista de fontes para essa localidade. O arquivo de especificação da fonte foi exteriorizada de modo que quaisquer mudanças futuras em torno de nomes de fonte pode ser facilmente verificado e acomodado sem fazer uma alteração de código. Além disso, a lista foi segregado baseado em fonte queda-back para o texto que aparece na interface do usuário e software para campos de texto no aplicativo.

A lista de fontes para cada localidade está listada no final deste post no blog. Chegar a esta lista não tem sido uma tarefa fácil e tem havido um enorme esforço de várias equipes para este. Alguns dos obstáculos que a equipe teve que limpar eram -

  1. Obter um conjunto exaustivo de fontes usadas em cada localidade e OS
  2. Segregar as fontes de acordo com a interface do usuário e texto de recuo
  3. Colocando estas fontes e de recuo lógica juntos em um arquivo xml
  4. Identificar a fonte prioritária para que a mesma lógica funciona em todas as plataformas de sistema operacional e versões
  5. Trabalhar com linguistas para testar cada tela com fontes aplicadas para facilitar a leitura e estética
  6. Iteração #3 e #4 com base na resposta lingüista "e, finalmente, chegar a fonte definitiva de recuo arquivo xml
Local UI Font queda back- TextField Font queda back-
Japonês Hiragino Kaku Gothic W3 PRO, Hiragino Kaku Gothic Pro W3, Meiryo UI, Meiryo, MS UI Gothic, MS Gothic, _sans Hiragino Kaku Gothic W3 PRO, Hiragino Kaku Gothic Pro W3, Meiryo, MS Gothic, _sans
Coreano AppleGothic regular, Gothic Malgun, Nova Gulim, Gulim, _sans AppleGothic regular, Gothic Malgun, Nova Gulim, Gulim, _sans
Tradicional Chinesa Heiti TC Luz, Lihei Pro, Microsoft JhengHei, Misturando-se, MingLiU_HKSCS, _sans Heiti TC Luz, Lihei Pro, Microsoft JhengHei, Misturando-se, MingLiU_HKSCS, _sans
Chinês Simplificado Organizações Internacionais Luz SC, STXihei, Microsoft YaHei, SimSun-18030, SimHei, SimSun, MS Canção, _sans Organizações Internacionais Luz SC, STXihei, Microsoft YaHei, SimSun-18030, SimHei, SimSun, MS Canção, _sans
Russo, Ucraniano Lucida Grande, MS Sans Serif, _sans Lucida Grande, MS Sans Serif, _sans
Todos os outros * Lucida Grande, Segoe UI, Tahoma, _sans Lucida Grande, Segoe UI, Tahoma, _sans

Todos os outros incluem francês, Alemão, Espanhol, Italiano, Português do Brasil, Holanda, Sueco, Dinamarquês, Finlandês, Norueguês, Tcheco, Polonês, Turco, Húngaro, Romeno, Esloveno, Eslovaco, e croata.
P.S: Estes font queda-backs foram definidas e testadas para Flex 4.5.1 SDK com componentes de ignição (usando TLF, Text Layout Framework)

Uma ressalva para observar aqui é que as fontes do sistema ficar mudando de tempos em tempos, que geralmente equivale a novas fontes, ou novas versões de fontes existentes, mas às vezes resulta em fontes existentes se tornando obsoleto. Em geral, embora, apoio linguístico em sistemas operacionais, em termos de cobertura glifo em fontes empacotados, fica melhor, não pior.

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

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

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

A declaração do problema(s)

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

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

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

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

A verificação da realidade

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

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

O maior custo de atraso internacionalização

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

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

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

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

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

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

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

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

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

Um aplicativo de calendário

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

 

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

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

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

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

Um site de viagens

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

Os benefícios do design global

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

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

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

Ver também

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Adobe fez uma apresentação sobre Moisés Tool Set no USTA Cúpula Tradução Ásia 2012

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

TAUS Asia Translation Summit 2012 foi organizado pela Translation Automation User Society (TAUS) em cooperação com China Center for Information Industry Development (CCID) e Translators Association of China (TAC). 80+ participantes de ambas as empresas de produtos como o Adobe, Baidu, EMC, Google e Microsoft e PEL participou na cimeira realizada em Pequim em abril 24 - 25, 2012, bem como o evento de meio dia cortesia TAUS Open Source Machine Translation Showcase realizada no mesmo local em abril 23. A cúpula proporciona aos participantes uma excelente plataforma para compartilhar conhecimento e experiência no domínio MT.

TAUS_2012_Beijing_PresentationFui convidado para dar ao USTA público uma introdução sobre o que a Adobe fez em MT open source. Na minha apresentação, Eu compartilhei como Adobe faz uso da ferramenta de código aberto MT Moses em seu fluxo de trabalho de localização. Nós desenvolvemos um conjunto de ferramentas chamadas Moses Tool Set para simplificar o uso de Moses. Ao utilizar esta ferramenta, o processo de formação de Moisés pode ser feito de uma maneira mais fácil e intuitiva. É constituída por 4 características: Corpus Clean Tool, Corpus Splitting Tool, Moses Training Harness, e Moses Scoring Harness. Cada recurso pode não apenas trabalhar de forma independente, mas ser combinados em um trabalho que permite aos usuários para completar o processo de treinamento todo em um clique.

Muitos audiência especialmente aqueles de LSPs que começou a sua aventura de MT de código aberto demonstrou interesse forte sobre o conjunto de ferramenta de Moisés. É feliz em ver que a busca por maneiras de melhorar a produtividade localização não é mais a responsabilidade apenas para os compradores de serviços linguísticos. Alguns LSPs também começaram suas tentativas no campo MT. Moses é uma boa opção para eles por causa de seu menor custo de entrada. Na discussão off-line, contudo, Eu tenho um monte de queixas destes usuários potenciais de Moisés sobre o uso de Moisés. Para aqueles que não mergulhar mais profundamente em tradução automática estatística, Moisés é muito complicado para começar. Muitos parâmetros são necessárias para gerar um motor de MT treinado. A falta de uma interface amigável é outra dor de cabeça para eles. Não admira que a audiência primeira coisa é ansioso para saber onde podem encontrar e baixar Moses Tool Set.

Na realidade, Moses Tool Set é um projeto open source. Ambos os seus pacotes de instalação e códigos-fonte estão disponíveis em Google Code.

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

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


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

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

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

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

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

Esclarecendo a terminologia

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

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

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

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

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

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

Como eles se relacionam entre si

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

Em síntese, no contexto de software:

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

Uma analogia na vida real

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

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

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

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


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

Onde está o problema

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

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

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

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


Internacionalização ajuda a evitar que este

A história curta (pontos a lembrar)

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

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

Ver também

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

 

Adobe Tooling Tradução Automática Para Moisés Apresentado no MT Summit 13

Este artigo foi escrito originalmente em Inglês. Textos em outros idiomas foram fornecidos via tradução automática.

Membros da equipe de MT Adobe estavam na mão na Cúpula MT 13 em Xiamen na China para apresentar as realizações da Adobe MT e demonstrar a próxima geração de ferramentas para a plataforma de código aberto Moisés MT. Membros da equipe da Adobe Ray Flournoy, Yu Gong, Christine Duran, e Jeff Rueppel fizeram a viagem para participar do 4 dia conferência bianual. A conferência se desloca da Europa para a América do Norte e este ano foi hospedado na China pela primeira vez. (Adobe Verão 2011 Estagiário Yifan Hi fez uma pausa de seu cargo tarefas de doutorado e apresentou sua pesquisa também.)

Yu Gong e Jeff Rueppel deu uma demonstração de 3 novas ferramentas Adobe para agilizar o desenvolvimento de motores de tradução automática utilizando o Moisés sistema de código aberto.

(Ferramenta da Adobe Aproveite Scoring)

Funcionários da Adobe demonstrou Scoring Harness Ferramenta da Adobe. (visto acima) O arnês de pontuação é um vários blocos de construção Adobe está colocando em prática para facilitar a automação de MT desenvolvimento de motores e implantação. O chicote de fios de pontuação automatiza o teste de motores de MT, usando padrões da indústria reconhecida pela qualidade motor de qualidade, (Azul, Nist, Meteoro, e TER) e vai permitir o ensaio dinâmico de novos motores contra motores já utilizados para a produção.

Adobe anuncia programa de Pré-lançamento Adobe para usuários Hebraicos

Este artigo foi escrito originalmente em Inglês. Textos em outros idiomas foram fornecidos via tradução automática.

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

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

  • Acesso ao download de Pré-lançamento do software / tecnologias e documentação técnica
  • Capacidade de reportar bugs & solicitar recursos para o software de pré-lançamento
  • Acesso aos fóruns de Pré-lançamento de usuário para compartilhar idéias diretamente com as equipes de produto Adobe e outros povos like-minded da comunidade do produto
  • Oportunidade de participar de vários produtos relacionados com inquéritos

 

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

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

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

Seguintes produtos plano de abrir-se oportunidades de pré-lançamento de teste com Oriente Médio Inglês - Árabe Habilitado, Oriente Médio Inglês - Hebraico Habilitado e Norte Africano francês constrói:

Adobe InDesign --Inscreva-se agora para participar do Adobe InDesign ME programa de pré-lançamento e visualização de novas funcionalidades emocionante!Inscreva-se agora

Adobe Illustrator - Cadastre-se para participar do Programa Adobe Illustrator ME e visualizar novas funcionalidades emocionante!Inscreva-se agora

Adobe Photoshop - Cadastre-se para participar do Programa Adobe Photoshop ME e visualizar novas funcionalidades emocionante!Inscreva-se agora

Nós aguardamos a sua participação neste programa de pré-lançamento. Em caso de qualquer problema de se precisar de mais informações, não hesite em contactar-nos menaprerelease@adobe.com

Em nome de – Ahmed Gaballah, Ashish Saxena, Avinash S. Kotwal, Iouri Tchernoousko

Anunciando programas Adobe Pré-lançamento para os usuários árabe

This article was originally written in Arabic. Text in other languages was provided by machine translation.

برامج ما قبل النشر من Adobe

تعتبر برامج ما قبل النشر من Adobe فرصة لتجربة المنتجات والتقنيات التي سيتم طرحها من Adobe وتقييمها والتأثير في خصائصها من قبل بيئة صغيرة وأكثر تركيزًا للمستخدمين . تعمل برامج ما قبل النشر على تسهيل عملية التطوير مما يتيح لـ Adobe مشاركة المنتجات في مرحلة التطوير لتجميع الملاحظات بشكل مبكر. تتاح لك في هذه العملية الفرصة لتشكيل المنتجات التي سيتم طرحها والتكيف مع المنتجات الجديدة بشكل أسرع.

تتوافر العديد من قنوات المشاركة للمساهمين في إصدار ما قبل النشر في Adobe:

- الوصول لتنزيل برامج و تقنيات ما قبل النشر والوثائق الفنية

- إمكانية الإبلاغ عن الأخطاء وطلب مزايا محددة عبر برنامج ما قبل الإصدار

- الوصول إلى منتديات مستخدمي إصدار ما قبل النشر لمشاركة الأفكار مباشرة مع فرق عمل منتج Adobe والأفراد الآخرين ذوي الأفكار المتشابهة في مجتمع المنتج

-الفرصة للمشاركة في الاستبيانات المختلفة الخاصة بالمنتج

يعتبر برنامج ما قبل النشر محاولة لإشراك المستخدمين الفعليين للمنتج – أنت – في مرحلة مبكرة من دورة تطوير المنتج، للاستماع إليك والاستفادة منك حول كيفية عمل المنتج من وجهة نظرك.

فرص إصدار ما قبل النشر الحالية: كيف يمكنني الانضمام؟

يمكنك استكمال نماذج التطبيق للتعبير عن اهتمامك بالانضمام إلى برنامج ما قبل النشر للمنتجات من Adobe. ستعتمد المشاركة كليًا على متطلبات البرنامج وبيانات اعتماد المشارك.

فيما يلي إصدارات المنتجات المتاحة للاختبار عبر برنامج إصدار ما قبل النشر:

- لإنجليزية – التي تدعم اللغة العربية، متاح للشرق الأوسط

- الإنجليزية – التي تدعم اللغة العبرية، متاح للشرق الأوسط

- الفرنسيةالتي تدعم اللغة العربية، متاح لشمال أفريقيا

Adobe InDesign – قم بالتسجيل الآن للمشاركة في برنامج ما قبل النشر للمنتج Adobe InDesign ME ومعاينة وظائف جديدة ومثيرة!انضم الآن

Adobe Illustrator – قم بالتسجيل للمشاركة في برنامج المنتج Adobe Illustrator ME ومعاينة وظائف جديدة ومثيرة!انضم الآن

Adobe Photoshop – قم بالتسجيل للمشاركة في برنامج المنتج Adobe Photoshop ME ومعاينة وظائف جديدة ومثيرة!انضم الآن

نحن نتطلع لمشاركتك في برنامج ما قبل النشر هذا. في حالة وجود أية مشكلات أو حاجتك إلى المزيد من المعلومات، الرجاء مراسلتنا على menaprerelease@adobe.com

On Behalf of – Ahmed Gaballah, Ashish Saxena, Avinash S. Kotwal, Iouri Tchernoousko