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.