Localização adequada de um aplicativo WinForms

Eu tenho um aplicativo WinForms que eu quero traduzir em vários idiomas. No entanto, eu não tenho nenhuma experiência com a localização de um aplicativo WinForms, e encontro informações muito contraditórias sobre este assunto.

Basicamente, o que eu quero é:

  • No código-fonte, quero apenas um arquivo por idioma
  • este arquivo é compilado no aplicativo principal na compilation – não há assemblies satélites ou arquivos de dados externos após a criação do aplicativo
  • O usuário pode selecionar o idioma, eu não preciso / quero detecção automática com base no sistema operacional
  • Isso deve conter principalmente strings e ints, mas também um CultureInfo

A maioria das soluções que vi também tem um arquivo .resx por formulário e / ou assemblies de satélite externos.

Eu tenho que rolar o meu próprio? Ou há algo no quadro já?

.net Framework 3.5 SP1, se isso é importante.

Edit: Na maior parte, o Visual Studio já oferece suporte para o que eu quero, mas há dois problemas. Quando eu configuro Form.Localizable para true, eu tenho esse suporte de designer legal, mas isso gera uma resx por formulário. A idéia de substituí-lo manualmente no InitializeComponent falha porque é um código escrito por designer que será substituído regularmente. Teoricamente, eu só quero a) replace a criação do ComponentResourceManager para apontá-lo para minha resx global eb) mudar a chamada para ApplyResources para a sobrecarga que leva um CultureInfo como terceiro parâmetro.

Parece que tenho que adicionar uma chamada de function ao meu construtor que chama depois de InitializeComponent () e sobrescreve seu comportamento. Isso parece terrivelmente ineficiente, mas o Visual Studio está certo quando avisa sobre tocar em InitializeComponent. No momento, estou rolando meu próprio framework de localização do WinForms …

Acabei de concluir um projeto C # .Net 3.5 com um problema semelhante. Estávamos escrevendo o plugin WinForms para um aplicativo multilíngüe existente com 8 idiomas (incluindo o inglês).

Foi assim que fizemos:

  1. Crie todos os nossos formulários e interface do usuário no idioma padrão, inglês.

  2. Coloque todas as nossas strings internas em um arquivo de recurso (coisas não vinculadas diretamente a um formulário, como mensagens de erro personalizadas e títulos de checkbox de diálogo, etc.)

Depois de concluirmos a maior parte do trabalho e dos testes, nós o localizamos.

  1. Cada formulário já tinha um arquivo .resx, mas este estava vazio. Nós definimos a propriedade ‘Localizable’ para true, o arquivo .resx foi preenchido com coisas como tamanhos de botões e strings.

  2. Para cada um dos outros idiomas, alteramos a propriedade ‘Language’ no formulário. Escolhemos a versão básica de cada idioma, por exemplo: “espanhol” em vez de “espanhol (Chile)”, etc., para que funcionasse para todos os dialetos “espanhóis”, eu acho.

  3. Em seguida, passamos por cada controle, traduzimos seu texto e redimensionamos, se necessário. Isso criou uma combinação de .resx por idioma e forma.

Fomos então deixados com 8 idiomas, 8 .resx para cada formulário e 8 .resx para as strings gerais. Quando compilado, a pasta de saída tinha o .dll que estávamos criando e, em seguida, uma subpasta para cada idioma com um arquivo .resources.dll.

Conseguimos testar as versões da interface do usuário no designer apenas alterando a propriedade language para verificar se tínhamos as strings e o layout corretos.

Ao todo, uma vez que temos nossas cabeças em torno dele, foi bastante fácil e indolor.

Nós não precisamos escrever nenhum ajuste personalizado no formulário

Eu estava fazendo uma pergunta semelhante sobre o ASP.NET e recebi uma primeira resposta – essa ferramenta e seu stream de trabalho também pode ser algo para você – dê uma olhada: Lingobit Localizer

Parece ser capaz de carregar o seu aplicativo Winforms e permite que você comece a traduzir suas etiquetas, etc., e veja os formulários enquanto o faz. Muitos outros resources também, como tradução incremental e memory de tradução (se você usar os mesmos termos repetidas vezes).

Parece bastante promissor (para o Winforms) – ainda não usei.

Aqui está uma extensa lista de ferramentas de localização em potencial do .NET – não tenho certeza, como elas funcionam e o que elas cobrem – dê uma olhada, talvez você encontre o que está procurando.

Marc

Este é um assunto enorme e há muitas maneiras de conseguir o que você quer. A estrutura fornece a base, mas uma solução completa requer que você implemente certos elementos por conta própria.

Por exemplo, a implementação do framework padrão é criar um arquivo .resx para cada recurso. No asp.net isso significa cada usuário ou controle de servidor ou página. Isso não se presta a manutenção fácil e, se você quiser mover resources para um database, precisará implementar seu próprio provedor.

Minha familiaridade com o WinForms é limitada, mas se você estiver usando o Silverlight ou o WPF, leia o trabalho de Guy Smith-Ferrier sobre o assunto em: http://www.guysmithferrier.com/category/Internationalization.aspx . Ele também tem alguns conjuntos de ferramentas que podem facilitar sua vida em: http://www.dotneti18n.com/Downloads.aspx .

Eu trabalhei com ele antes e nunca encontrei ninguém com uma melhor compreensão do assunto.

Eu não tenho uma solução para seu primeiro e segundo requisito, mas lembre-se de que localizar um formulário não é tão simples quanto traduzir cada palavra. Você precisa verificar se cada texto traduzido se encheckbox em seu respectivo controle. Além disso, talvez você tenha um ícone ou uma imagem que precisa mudar em outra cultura.

Para o seu ponto três, você pode alterar o idioma manualmente com as seguintes linhas:

 CultureInfo ci = new CultureInfo("fr"); Thread.CurrentThread.CurrentUICulture = ci; 

O que você está pedindo:

  1. nenhum arquivo de recurso de satélite
  2. apenas um tamanho e posicionamento de controle por formulário.
  3. muitas linguagens embutidas no executável.

Não é capaz de fazer o IDE do Visual Studio.

O que seria necessário é algum trabalho personalizado, basicamente cumprindo todas essas etapas:

  • Adquira um gerenciador de resources personalizado que manipule arquivos de resources TMX.
  • Coloque todas as suas strings localizáveis ​​em um arquivo TMX.
    • Torne esse arquivo TMX um recurso incorporado em seu projeto.
  • Em seu construtor Form, crie seu TMX ResourceManager, carregando o arquivo TMX de seus resources incorporados.
  • Em seu código, use seu tm ResourceManager em vez do ResourceManager padrão para obter strings localizadas.
    • Deixe o formulário usar o ResourceManager padrão para obter todas as coisas do designer, exceto as strings.
  • Obtenha seu arquivo TMX com as novas traduções do idioma.
    • Mais pode ser adicionado na próxima versão do seu projeto, apenas adicionando-os a este arquivo TMX antes de compilar.

RECURSOS: (não é uma lista exaustiva, por qualquer meio)