Mudlet: Configure um serviço de tradução baseado na web para o Mudlet

Existe o POEditor como integração com o github, que permite traduzir XLIFF
(que supostamente são suportados pelo qt linguist). E eles têm um sistema operacional
licença.

Outra opção é o Qordoba, que parece não custar nada e nativamente
suporte a arquivos ts.

Nunca usei nenhum serviço/aplicativo de tradução, então não tenho preferências.

Vadim Peretokin [email protected] schrieb am So., 9 de abril de 2017,
13:14:

Precisamos tornar super fácil para as pessoas contribuirem para traduzir o Mudlet

• isso significa algo baseado na web, onde a única barreira é apenas fazer login.
  Pode haver um serviço baseado na web existente que possa nos oferecer uma
  licença de código aberto para obter a configuração.

Alternativas disponíveis:
Launchpad https://translations.launchpad.net/ - seu futuro é
questionável no entanto

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Mudlet/Mudlet/issues/856 ou silencie o tópico
https://github.com/notifications/unsubscribe-auth/ABAeDUJoAsg-zvnOq1YUvuIqn-fbRwcCks5ruL2WgaJpZM4M3_u1
.

Re: XLIFF the _Qt Linguist Manual: Tradutores_ Qt Doc notes:

__Traduzindo Strings__
Você abre arquivos de origem de tradução (TS) no Qt Linguist para tradução. Os arquivos TS são arquivos XML legíveis por humanos contendo frases de origem e suas traduções. Os arquivos TS geralmente são criados e atualizados por lupdate. Se você não tiver um arquivo TS, consulte o Release Manager para saber como gerar um.
Você pode usar o Qt Linguist também para traduzir arquivos no formato internacional XML Localization Interchange File Format (XLIFF) que são gerados por outros programas. No entanto, para projetos Qt padrão, apenas o formato de arquivo TS é usado. A versão mínima suportada para arquivos no formato XLIFF é 1.1.

Existem plataformas de tradução baseadas na web que têm enormes vantagens sobre os aplicativos de desktop: não há necessidade de instalar nenhum software, sugere traduções para texto já traduzido e etc.

@SlySven Eu li isso, e é por isso que eu disse o que disse. Parece não ser totalmente suportado ou uma reflexão tardia, e é por isso que adicionei supostamente (nunca testei).

@vadi2 Os produtos que mencionei são plataformas baseadas na web. Mas você ainda precisará usar o qt linguist para tornar a saída dessas plataformas utilizáveis ​​pelo framework de tradução Qt. O que também nos liga aos formatos suportados TS files e XLIFF .

Eu joguei com Linguist e a interface do usuário é muito boa até onde eu sei (sou fã :heart_eyes:), ele replica os diálogos da interface do usuário {e mostra o código-fonte de onde a string de texto se origina para C++ originando QStrings } para que você possa ter uma boa ideia de como eles ficarão nos diferentes idiomas e poderá trabalhar em várias traduções simultaneamente. Eu só espero que o Qt seja mais rígido em não reordenar o conteúdo dos arquivos TS desnecessariamente para manter o ruído do git baixo quando um arquivo é atualizado por um contribuidor - ao contrário, digamos, QGridLayouts em arquivos .ui. * suspiro *

Quanto à necessidade de usar o Qt Linguist - acho que, como estamos usando o Qt Libraries, geralmente estamos comprometidos com ele (como em _Pig_ em vez de _Chicken_ níveis de compromisso em um _bacon-and-egg sarnie_) além de ser nativo gettext seria _mais difícil_ de uma maneira ruim, eu acredito.

Parece que estou interessado em ver o Qt Linguist exportar para algo baseado na web, com a opção de as pessoas instalarem e visualizarem suas traduções em tempo real, se quiserem. Vou dar uma olhada nos serviços que você mencionou @keneanung , eles parecem bons.

Eu também tinha Transifex em mente, mas isso não parece estar mais indo tão bem.

Outra plataforma de tradução web: https://hosted.weblate.org/projects/tilix/translations/

Veja como o projeto Mozilla lida com localização e tradução: https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Quick_start_guide/Translation_phase

Outro grande olhar aprofundado sobre várias alternativas e o processo em geral nesta dissertação de mestrado sobre “Traduções em software livre”: https://larjona.wordpress.com/translations-in-libre-software/

Obrigado @Kebap , li o artigo que você vinculou. Estou interessado em Weblate e Transifex - vou dar uma olhada neles.

Eu gostaria que isso tivesse a menor barreira de entrada possível e que excluísse a tradução baseada em desktop, onde a pessoa tem que baixar e instalar o software, depois procurar os arquivos certos antes que eles tenham a chance de começar a trabalhar.

Weblate parece bom e de código aberto, mas sua versão hospedada também está fora do ar agora - assim como todas as traduções hospedadas, como para o projeto Tilix. Não é bom. Também estou desconfiado de hospedar mais coisas em nosso servidor porque já está rodando no limite.

Vou experimentar a demo Transifex. Eles suportam código aberto e parecem ser uma loja muito maior, com muito menos probabilidade de cair, ao contrário do Weblate.

Com isso dito, se a integração do Weblates Git realmente funcionar, será muito melhor usá-la, pois _deve_ atualizar automaticamente o novo texto de origem do Git e talvez confirmá-lo de volta. O Transifex, por outro lado, está exigindo que eu carregue manualmente os arquivos para traduzir.

Embora o Transifex suporte arquivos .ts nativamente, parece travar no upload. Usar ts2po e fazer upload de arquivos .po funcionou.

Parece que você pode ter atualizações bidirecionais automáticas entre Transifex e Github com algum middleware: https://docs.transifex.com/integrations/github-txgh

Consegui baixar um .po com a tradução intacta do Transifex, mas po2ts engasga no arquivo com um erro de codificação Python:

po2ts: WARNING: Error processing: input ./for_use_mudlet_rupo_1_ru.po, output ./for_use_mudlet_rupo_1_ru.ts, template None: 'ascii' codec can't encode characters in position 1994-1999: ordinal not in range(128)

Vou deixar o projeto Transifex em https://www.transifex.com/mudlet/mudlet/dashboard se mais alguém quiser traduzir @Kebap @keneanung. Daremos uma chance ao Weblate em seguida.

O Weblate é bom - ele tem uma tonelada de opções de login de terceiros, então entrar nele é realmente livre de atritos.

@vadi2 escreveu:

Consegui baixar um .po com a tradução intacta do Transifex, mas po2ts engasga no arquivo com um erro de codificação Python:

Acho que li em algum lugar que a versão de po2ts só funciona para uma especificação antiga do arquivo .ts e precisava de atualização (no final, eu acho) - observo que vem do Translation Toolkit de Traduza o código-fonte do House página de internacionalização do mixxx .

Na verdade, esse erro de "codificação" soa como se estivesse tentando produzir um arquivo .ts que a codificação é ASCII e NÃO UTF-8, portanto, está barfando no ponto em que precisa usar alguns caracteres (em uma string _translated_) que não são ASCII...

Essa página foi atualizada pela última vez há quatro anos! O processo para desenvolvedores está fora
de data, eu acho. Essa é uma documentação de tradução bastante impressionante
no entanto!

Em terça-feira, 19 de setembro de 2017, 18h18, Stephen Lyons [email protected] escreveu:

@vadi2 escreveu:

Consegui baixar um .po com a tradução intacta do Transifex,
mas po2ts engasga no arquivo com um erro de codificação Python:

Acho que li em algum lugar que a versão deles do po2ts só funciona para um antigo
especificação do arquivo .ts e atualização necessária (no final, eu acho) - eu
observe que ele vem do Translation Toolkit
http://toolkit.translatehouse.org/ da fonte Translate House Github
código https://github.com/translate/translate e a versão mais recente é
2.2.5 (não sei o que eles estão usando) no momento da redação. Encontrei um
página da web de outro projeto (não tenho certeza se foi baseado no GitHub, mas o
processo geral para eles parecia o tipo de coisas que teremos que fazer: mixxx
página de internacionalização
https://mixxx.org/wiki/doku.php/internationalization .

—
Você está recebendo isso porque foi designado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Mudlet/Mudlet/issues/856#issuecomment-330592819 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAGxjEdeBPs-7fDkUwfoLjUt48eJJhl0ks5sj-lagaJpZM4M3_u1
.

Weblate não parece estar em uma boa posição. Ainda não recebi uma resposta para meu aplicativo hospedado, e o projeto não recebe muito por meio de atualizações. De volta ao Transifex é.

Dicas sobre como configurar o Transifex com o Qt: https://forum.qt.io/topic/36750/qt5-ts-files-and-transifex-continuous-translation-localization

https://bugreports.qt.io/browse/QTBUG-1136 :

finalmente, o linguista está essencialmente no suporte de vida - cedemos o terreno a ISVs especializados nesta área.

O Qt Linguist é uma tecnologia sem saída - não terá nenhum recurso daqui para frente, então temos que usar uma plataforma baseada na web aqui.

Vou tentar colocar as traduções do Transifex em funcionamento agora que o #1334 está disponível.

Apenas para reiterar o que mencionei na referência cruzada do Kebap que o crowdin também parecia uma escolha válida para um projeto de código aberto como o nosso - e eles podem lidar com arquivos Qt .ts e também tem integração com Github - o recurso de pseudolocalização também deve nos ajudará a evitar problemas na GUI porque não estruturamos o texto corretamente ( eu acho ) e definitivamente nos ajudará a garantir que deixamos margem suficiente para linguagens com strings maiores que en-US ...

crowdin parece bom - vamos ver como ele se compara ao Transifex, eu tenho um projeto de teste aqui .

@SlySven que o código

Eu descobri - o crowdin também tem essa opção. Basta selecionar "ocultar" nas configurações das tags do editor :

Isso significa que não precisamos mais fazer o desmembramento de código que o

Estou feliz com a sugestão de usar @crowdin para traduções de @SlySven. @Kebap , @keneanung , @SlySven seus pensamentos?

Assim que concordarmos, vou atualizar o projeto no crowdin para ser oficial, solicitar uma licença de código aberto e começar a divulgar os tradutores.

Ei,

Faço parte da equipe Crowdin e terei prazer em ajudar com mais configurações, se necessário! Sinta-se à vontade para me mencionar se surgir alguma dúvida

Estou bem com crowdin também. Sua interface do usuário tem sido confusa no início, mas tenho certeza que nós (eu) vamos nos acostumar com isso.

Confesso que não olhei atentamente para o Transifex, pois desliguei mentalmente, considerando-o, pois entendi que ele não lidava bem com o formato atual do Qt .ts bem / diretamente - isso mudou ou eu estava incorreto nessa crença?

Uma coisa sobre o Crowdin que estou vendo nos recentes commits do git é que você estava carregando vários arquivos .ts que foram configurados localmente para um idioma específico. Você meio que corrigiu isso agora enviando apenas um único arquivo mudlet_en.ts mas isso ainda não parece certo para mim. Você pode querer remover ou comentar os TRANSLATIONS = linhas no mudlet.pro arquivo e tem um shell script que é executado (na base da fonte):

lupdate -recursive ./src/ -ts ./translations/mudlet.ts

para gerar um único arquivo não específico de idioma para passar para o processo de tradução do Crowdin e fazer com que ele produza os arquivos mudlet_xx_YY.ts que queremos (já alterei uma configuração no Crowdin para especificar o _xx_YY language+locale sufixos onde originalmente parecia estar definido apenas como _xx language). Isso ainda resultará em um conjunto de arquivos a serem copiados de volta para o mesmo diretório pronto para lrelease .

BTW Deixar o arquivo simples sem sufixo é útil porque significa que as partes interessadas em idiomas minoritários podem copiá-lo e renomeá-lo para trabalhar em particular se desejarem um idioma diferente e descoberto com o Qt Linguist fornecido. {Talvez um pirata para 19 de setembro, por exemplo!!!}

Eu acho que as etapas anti-obfuscação de HTML que eu tomei parecem ter se tornado um pouco menos necessárias, já que o plugin Qt Designer parece ter se tornado um pouco menos ansioso para desmontar o HTML nas últimas versões do Qt. Ainda não estou totalmente convencido de que não vai mexer e mudar as coisas, digamos, forçando o uso de fontes específicas que a última pessoa a editá-lo tem em seus sistemas, em vez de deixá-lo como um genérico que pode funcionar em todas as plataformas. Vou dar outra olhada e relatar isso aqui porque afetará como gravamos esse HTML em nosso trabalho.

Confesso que não olhei atentamente para o Transifex, pois desliguei mentalmente, considerando-o, pois entendi que ele não lidava bem/diretamente com o formato Qt .ts atual - isso mudou ou eu estava incorreto nessa crença?

Eu também estava, parece que mudou: https://docs.transifex.com/formats/qt-ts

Eu não pretendo usar o plugin Qt Designer, então qualquer desmontagem que ele faça não é relevante - o crowdin lida com as traduções bastante bem por conta própria, e sua renderização HTML com o estilo "ocultar" é tolerável.

Ah, ainda está fazendo isso - inserindo tabelas e um DTD - então, o que é mais fácil de ler e analisar por humanos, isso:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html><head><meta name="qrichtext" content="1" /><style type="text/css">
p, li { white-space: pre-wrap; }
</style></head><body style=" font-family:'FreeSans'; font-size:9pt; font-weight:400; font-style:normal;">
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><span style=" font-size:large; font-weight:600;">Welcome to Mudlet!</span></p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Click on one of the MUDs on the list to play.</p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">To play a game not in the list, click on <img src=":/icons/list-add_small.png" /><span style=" color:#555753;">New</span>, fill in the <span style=" font-style:italic;">Profile Name</span>, <span style=" font-style:italic;">Server address</span>, and <span style=" font-style:italic;">Port</span> fields in the <span style=" font-style:italic;">Required</span> area.</p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">After that, click <img src=":/icons/dialog-ok-apply_small.png" /><span style=" color:#555753;">Connect</span> to play.</p>
<p style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Have fun!</p>
<p align="right" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">The Mudlet Team <img src=":/icons/mudlet_main_16px.png" /></p></body></html>

ou isto, que faz o mesmo no que nos diz respeito:

<html><head/><body><center><big><b>Welcome to Mudlet!</b></big></center></p>
<p><center>Click on one of the MUDs on the list to play.<center></p>
<p><center>To play a game not in the list, click on <img src=":/icons/list-add_small.png"/> <span style="color:#555753;">New</span>, fill in the <i>Profile Name</i>, <i>Server address</i>, and <i>Port</i> fields in the <i>Required</i> area.<center></p>
<p><center>After that, click <img src=":/icons/dialog-ok-apply_small.png"/> <span style=" color:#555753;">Connect</span> to play.</center></p>
<p>Have fun!</p>
<p align="right">The Mudlet Team <img src=":/icons/mudlet_main_16px.png"/></p></body></html>

Tecnicamente, tudo isso é rich-text Qt, que é apenas um subconjunto de HTML (então, por que forçar a inclusão do HTML 4.0 DTD estrito?)

Mesmo mostrando < e > aqui em vez de < e > no arquivo bruto que os tradutores verão, acho que está claro o que vai ser mais fácil de trabalhar na ausência de um widget de exibição HTML/Qt Rich Text...

Acho que li em algum lugar que as linguagens CJK realmente não devem usar efeitos de fonte em negrito ou itálico (em vez disso, acho que eles usam o equivalente a um acento de ponto em uma borda do glifo) - então, nesses casos, a marcação pode estar envolvida em o processo de tradução...

Executar scripts de shell não é portátil (para Windows), então prefiro não fazer isso. O arquivo mudlet_en.ts atual parece estar funcionando bem?

É sexta-feira, então vamos chegar a uma conclusão sobre isso nos próximos dias para que possamos começar as próximas etapas, que acho que seriam:

1) processo para tradutores reportarem strings confusas - se um tradutor não conseguir entender, é provável que nossos usuários também não entendam
2) processo de tradução real e como ele funcionaria com nosso fluxo de trabalho

Eu recomendaria primeiro pensar mais nos detalhes dos processos que precisamos, e só então decidir qual ferramenta se encaixa melhor neles.

Até onde posso ver agora, temos algumas fontes principais de texto diferentes:

• Cliente Mudlet em si
• Site do Mudlet
• Wiki do Mudlet
• "outros" textos espontâneos precisam ser incluídos manualmente

Então os processos para cada um são os mesmos, mas precisam ser revisados ​​separadamente:

• Descubra uma maneira de diferenciar textos desatualizados de textos atuais relevantes que precisam de tradução.
• Obtenha textos de fontes (veja acima). Isso pode ser automatizado com qualquer ferramenta? Quem deve ser o responsável?
• Obtenha textos na ferramenta de tradução.
• Traduzindo dentro da ferramenta (ok, isso é esperado, mas também precisa de uma boa interface e fluxos de trabalho)
• Os tradutores relatam strings confusas de volta à equipe do Mudlet com informações sobre como elas precisam ser ajustadas.
• A equipe do Mudlet atualiza o texto na fonte. Seja por relatos, seja por evolução natural.
• Textos atualizados da fonte precisam de atualizações na ferramenta de tradução. Exporte e importe novamente, mais diff.
• Os textos traduzidos serão finalizados. Exporte-os da ferramenta de tradução. Automação de novo?
• Importe o texto traduzido para a fonte.
• Exibição de traduções na fonte. Aqui precisaremos de algum tipo de alternância de idioma em cada fonte.

Percebi alguns plugins para Wordpress e Mediawiki, além de integração no Crowdin e Transifex, mas não tive muito tempo para pesquisar tudo isso com mais detalhes.

Eu adoraria um processo mais automatizado para todas as etapas acima e escolheria qualquer ferramenta que pudesse suportar melhor.

No que diz respeito ao código-fonte/diálogo (formulários):

• Descubra uma maneira de diferenciar textos desatualizados de textos atuais relevantes que precisam de tradução.
• Obtenha textos de fontes (veja acima). Isso pode ser automatizado com qualquer ferramenta? Quem deve ser o responsável?
  
  
  
  • Ambos são feitos com o comando lupdate que extrai textos fonte, adivinhem, o código fonte e adiciona/atualiza os registros deles no - o que eu acho que deveria ser um arquivo mudlet.ts neutro de linguagem (o o mudlet_en.ts atual sinaliza para algumas partes que ele possui especificamente traduções do idioma inglês - enquanto - com a forma como o usaremos como o código-fonte ==> O meio de transferência de data do Crowdin será usado para todos, exceto o inglês (americano ). Se não for invocado com a opção --no-obsolete , as strings existentes, mas agora desaparecidas, não serão removidas - que é o que queremos pelo menos durante os estágios de desenvolvimento. A razão pela qual proponho gerar um separado para o en-US locale porque será um local muito curto que contém apenas strings para plurais, ou seja, lugares onde teríamos strings de origem como "excluindo %n quarto(s)" para que, nesse caso, "excluindo 1 quarto" ou "excluir 2 quartos" são usados.
  
  
• Obtenha textos na ferramenta de tradução.
  
  
  
  • O processo de atualização da ramificação de desenvolvimento deve fazer com que o acima aconteça e o .ts atualizado seja carregado (sugiro) da compilação linux CI (porque é mais fácil para nós fazer o script)
  
  
• Traduzindo dentro da ferramenta (ok, isso é esperado, mas também precisa de uma boa interface e fluxos de trabalho)
• Os tradutores relatam strings confusas de volta à equipe do Mudlet com informações sobre como elas precisam ser ajustadas.
  
  
  
  • Parece que o crowdin permite que qualquer pessoa faça um comentário ou levante um problema sobre qualquer string de origem que será pelo menos visível para o gerente (mas pode estar aberto a mais partes)
  
  
• A equipe do Mudlet atualiza o texto na fonte. Seja por relatos, seja por evolução natural.
  
  
  
  • Incluindo lugares onde o texto de origem é confuso ou incorreto na forma en_US esperada - por exemplo, eu posso ter usado license (en-GB noun , cf license as en-GB verb ), mas é sempre licença em en-US para ambas as formas.
  
  
• Textos atualizados da fonte precisam de atualizações na ferramenta de tradução. Exporte e importe novamente, mais diff.
  
  
  
  • execute novamente lupdate - mas isso deve acontecer naturalmente por meio de scripts de CI nas atualizações de 'desenvolvimento' da ramificação
  
  
• Os textos traduzidos serão finalizados. Exporte-os da ferramenta de tradução. Automação de novo?
  
  
  
  • Um de nós pode "Baixar traduções" como um conjunto completo de arquivos mudlet_xx_YY.ts manualmente do Crowdin e enviá-los para o diretório /translations - lembre-se de que esses arquivos não são atualizados por lupdate exceto, talvez, para o mudlet_en_US.ts somente no mudlet.ts .
  
  
• Importe o texto traduzido para a fonte.
  
  
  
  • Não é bem o que é necessário, os textos de tradução não são lidos pelo aplicativo a partir dos arquivos .ts . Em vez disso, uma vez que eu tenha o código revisado e publicado em público, o aplicativo mudlet lerá as traduções em tempo de execução carregando o arquivo binário mudlet_xx_YY.qm selecionado (junto com o Qt apropriado - que observo que já estamos distribuindo com as versões do instalador!) Então, inicialmente, imagino que um de nós executará lrelease para converter os arquivos .ts arquivos .qm e enviá-los para o repositório git como Nós vamos. Eventualmente Vadim sugeriu que enviaríamos as versões de lançamento com um conjunto de arquivos .qm incluídos como um arquivo de recurso. Isso é apropriado para as versões do instalador, mas os empacotadores do Linux esperam armazená-los, digamos, em /usr/share/mudlet/translations somente leitura (ao lado dos arquivos externos Mudlet lua). Eu tenho um código de protótipo que permitirá que esses dois arranjos sejam manipulados, mas permitindo que o usuário carregue arquivos de tradução de outro lugar (possivelmente do diretório /translations no código-fonte) permitiria o desenvolvimento autônomo de traduções para outras línguas minoritárias por partes interessadas com a ferramenta Qt original Linguist - também permitiria que os desenvolvedores trabalhassem em casos privados/teste.
  
  
• Exibição de traduções na fonte. Aqui precisaremos de algum tipo de alternância de idioma em cada fonte.
  
  
  
  • Da experimentação usando o QLangaugeEvent é mais complexo do que precisamos, pois é acionado toda vez que QQTranslator::load(...) é chamado - descobri que é mais simples ter a classe emit mudlet emit a (void) signal_translatorChangeCompleted(const QString&, const QString&) onde os argumentos dos códigos xx_YY atuais e anteriores (language_COUNTRY/REGION) não são amplamente utilizados, exceto para IIRC o Host que gera um evento lua para script /package manipuladores de eventos para trabalhar. Esse sinal é enviado para cada classe com textos GUI persistentes para um slot_guiLanguageChange() onde ele chama o retranslateUi(this) que é definido em cada classe que também usa setupUi(this) desde que você configure o opção no Qt IDE corretamente (não sei como isso funciona ao usar qmake diretamente):
    
    
    
    essa chamada alterará as traduções em cada string traduzível nos formulários/diálogo e, em seguida, teremos que regenerar todos os textos da GUI que criamos em tempo de execução, levando em consideração quaisquer condições que possam ter causado a junção de diferentes textos. Isso não é tão ruim quanto parece porque só precisamos alterar persistente - ou seja, está por aí por um longo tempo - porque os textos transitórios usarão automaticamente a nova tradução sempre que tr(...) for usado para criá-los.
  
  

Isso não é tudo o que tenho sobre este tópico, mas posso ver como a maioria das etapas deve seguir para os textos da GUI do aplicativo ...

Obrigado por esses detalhes SlySven! Parece-me, talvez você tenha feito isso antes? Para outra aplicação? Com Corwdin? Isso tornaria a tradução do próprio aplicativo Mudlet muito mais fácil.

Por outro lado, ainda temos as mesmas perguntas para as outras fontes de texto no universo Mudlet, como documentação wiki, site Mudlet e textos adicionais que podem precisar ser incorporados um pouco manualmente, conforme explicado no meu último post acima.

Eu não passei pela resposta acima completamente, mas o Crowdin tem integração com o Github que não leva em conta - https://github.com/Mudlet/Mudlet/pull/1692 é um PR gerado automaticamente, não precisaremos fazer qualquer upload ou download manual; basta mesclar os PRs. Assim, o processo será um pouco mais simples do que o descrito!

Pessoal, o teste do crowdin expirará em 4 dias, então preciso de um sim / não - parece que estamos felizes com isso até agora

Houve um yay de mim!

Oi! ;)

Eu tentei https://crowdin.com/ … para traduzir tudo bem, não sei se é bom para feedback rápido, solicitações e assim por diante … como "contestualização" para uma tradução ou exemplo ...

E a seção de comentários no crowdin?

Olá @Joker-ITA,

Na verdade, existem várias maneiras de adicionar contexto extra para tradutores:

1) No editor, clique em "Editar contexto" abaixo da string para fornecer mais informações aos tradutores;
2) Você pode deixar um comentário para qualquer string no editor (no painel direito, digite seu comentário);
3) Adicione contexto para qualquer string através das configurações do projeto -> guia Strings;
4) Aposto que você tem alguns termos específicos que os tradutores comuns podem não entender, portanto, faz sentido criar um glossário e enviá-lo para o Crowdin. Mais informações . Pode ser até planilha Excel com 2 colunas: Termo & Descrição;
5) Se você tiver comentários dentro de arquivos (por exemplo, Android XML, strings iOS, .properties, .yml, Google Chrome JSON), eles serão importados automaticamente junto com o arquivo;
6) Você pode enviar a captura de tela para o Crowdin e marcar qualquer string nela: https://support.crowdin.com/adding-screenshots/
7) Se falamos de webapp l10n, faz sentido experimentar nosso recurso In-Context para permitir que tradutores traduzam diretamente em seu site.

São apenas as principais maneiras de contextualizar textos para tradução 😄

@Kebap escreveu:

Obrigado por esses detalhes SlySven! Parece-me, talvez você tenha feito isso antes? Para outra aplicação? Com Corwdin? Isso tornaria a tradução do próprio aplicativo Mudlet muito mais fácil.

Apenas manualmente usando as próprias ferramentas do Qt (passei algumas semanas no sul da França nos últimos dois anos trabalhando nos detalhes). Ainda usaremos dois deles - lupdate & lrelease - mas estamos substituindo Qt Linguist (sendo a ferramenta que adiciona as traduções aos textos-fonte presentes em vários .ts arquivos gerados por lupdate para cada tradução, antes de lrelease transformá-los nos arquivos mudlet_xx_YY.qm específicos de idioma/local necessários - novamente um por tradução de idioma/local oferecido) com Crowdin, que pegará um único arquivo mudlet.ts † e gerará os arquivos mudlet_xx_YY.ts .

Uma diferença importante entre usar linguist e o que faremos usando o Crowid é que podemos fugir sem:

TRANSLATIONS =

linha no arquivo de projeto para Crowid.

† Na verdade acho que precisaremos de dois arquivos - mudlet.ts para todas as localidades e que passarão pelo processo Crowdin e mudlet_en_US.ts que serão extraídos com a opção -pluralonly e terão apenas algumas traduções para converter mensagens como tr("deleted %n room(s)", "", roomCount) para "deleted 1 room" ou "deleted 2 rooms" dependendo do valor de roomCount e provavelmente pode ser feito por você mesmo...

Ótimo - vamos com Crowdin :)

Vou ajustar o nome do arquivo como @SlySven sugere e configurar o projeto no Crowdin para que as pessoas possam começar a traduzir. Quaisquer traduções de teste existentes que fizemos serão salvas na memória de transações, portanto, reaplicá-las será muito fácil.

Respondendo às perguntas do @SlySven :

• Descubra uma maneira de diferenciar textos desatualizados de textos atuais relevantes que precisam de tradução.
  
  
  
  • lupdate ferramenta faz isso
  
  
• Obtenha textos de fontes (veja acima). Isso pode ser automatizado com qualquer ferramenta? Quem deve ser o responsável?
• Obtenha textos na ferramenta de tradução.
  
  
  
  • executamos manualmente lupdate e os comprometemos com development - esta parte pode ser automatizada diariamente por Travis
  
  
  • crowdin automaticamente os pega devido à integração do github
  
  
• Traduzindo dentro da ferramenta (ok, isso é esperado, mas também precisa de uma boa interface e fluxos de trabalho)
  
  
  
  • interface de tradução do crowdin
  
  
• Os tradutores relatam strings confusas de volta à equipe do Mudlet com informações sobre como elas precisam ser ajustadas.
  
  
  
  • escreva um problema no crowdin
  
  
• A equipe do Mudlet atualiza o texto na fonte. Seja por relatos, seja por evolução natural.
• Textos atualizados da fonte precisam de atualizações na ferramenta de tradução. Exporte e importe novamente, mais diff.
  
  
  
  • crowdin pega
  
  
• Os textos traduzidos serão finalizados. Exporte-os da ferramenta de tradução. Automação de novo?
  
  
  
  • sim, crowdin abre automaticamente um PR: https://github.com/Mudlet/Mudlet/pull/1717
  
  
• Importe o texto traduzido para a fonte.
• Exibição de traduções na fonte. Aqui precisaremos de algum tipo de alternância de idioma em cada fonte.
  
  
  
  • @SlySven fará mágica aqui :)
  
  

Qual é a necessidade de ter um arquivo de traduções separado apenas com os plurais?

As instruções de tradução estão disponíveis em https://wiki.mudlet.org/w/Translating_Mudlet