Mudlet: Pare de perder traduções ao modificar

Alguma ideia de como remediar? @crowdin

Onde você traça a linha entre manter ou descartar uma tradução?

Para mim, colocar a tradução de volta na TM parece o melhor, é muito fácil retirá-la novamente e o tradutor pode decidir se quer reutilizar o texto ou não.

Exatamente, essa linha precisa ser desenhada individualmente para cada string, como sugere a captura de tela do Crowdin.

Gostaria de receber uma opção para os tradutores iniciarem esse diálogo pop-up depois de puxar as cordas do github.

No momento, eles não conseguem nem distinguir quais strings foram traduzidas anteriormente, para corrigir rapidamente um puxão.

Não acho razoável gastar horas em cada modificação, pesquisando quais traduções foram quebradas.

Ao usar o próprio Linguist do Qt (ou melhor lupdate ) para atualizar um monte de arquivos .ts específicos do idioma diretamente do código-fonte, lupdate tem uma opção:

          Drop all obsolete and vanished strings.

Somente se essa opção for fornecida, isso fará com que não sejam usados ​​ou obsoletos - que é como eu acho que uma alteração no comentário está sendo tratada pelo CrowdIn - strings a serem removidas dos arquivos .ts . De alguma forma, precisamos fazer com que o CrowdIn se comporte assim para nós. :rezar:

É importante ressaltar que não acho que uma alteração em um comentário (embora possivelmente uma alteração em uma desambiguação seja diferente) deva limpar a tradução - pode ser aceitável que ele perca o status de "aprovado", mas não seja esquecido.

Olá a todos,

Esteja ciente de que você também pode salvar traduções para strings modificadas ao atualizar o arquivo por CLI / API / GitHub, especificando o parâmetro update_option no arquivo de configuração ( crowdin.yml ) armazenado em seu repositório.

Mais informações:
https://support.crowdin.com/configuration-file/#changed -strings-update

Depois de fazer a alteração, pause e retome a integração no Crowdin para aplicar as alterações

Espero que seja exatamente o que você precisa!

Obrigado pela resposta!

@Kebap qual opção você gostaria?

Obrigado rapazes. Isso é incrível. Analisará as opções em detalhes.

Eu gostaria de tentar a opção "update_as_unapproved", isso parece ser um bom compromisso: as traduções permanecem intactas, mas perdem seu status de aprovado.

Agora, quando eu testei isso, não parecia funcionar. Strings ainda perderam suas traduções. Cheguei até a aprimorar o layout breve criado automaticamente do arquivo yaml de configuração , de modo a refletir exatamente o exemplo fornecido na seção Base de conhecimento vinculada acima.

Ainda assim, o Crowdin aparentemente, infelizmente, apenas substituiu as strings, em vez de manter suas traduções e apenas remover a aprovação. Estou fazendo errado?

A string anteriormente tinha tradução e aprovação (a aprovação parece invisível no arquivo .ts?)

A opção de atualização "update_as_unapproved" foi testada com layout yaml curto e longo, ambos com o mesmo resultado

Depois de modificar a string (ou comentário), o Crowdin agora mostra a string modificada sem tradução e aprovação

Crowdin Diff relata strings como "excluídas e adicionadas" e não "mantidas, mas perdidas sua aprovação"

-- Por favor, responda acima desta linha --

        Hi everyone,

Parece que o problema é que no seu projeto seus arquivos são .html e
.ts. Os arquivos desse tipo não têm uma estrutura KEY:VALUE clara,
portanto, quando você atualiza os arquivos, cada string alterada é
considerados como novas cordas. É o comportamento esperado do sistema,
mas vou perguntar aos devs se há algo que possa ser feito neste
caso, uma vez que eles estão no escritório!

Como você avaliaria minha resposta?
Ótimo [1] Ok [2] Não é bom [3]

--
Sinceramente,
Olga Kuhta
Gerente de sucesso do cliente

Links:

[1]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/1/
[2]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/2/
[3]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/3/

    > On Sat, Sep 8, 2018 at 1:34:23 EEST, Mudlet/mudlet <[email protected]> wrote:

Eu gostaria de tentar a opção "update_as_unapproved", isso parece ser um
bom compromisso: as traduções permanecem intactas, mas perdem a aprovação
status.

Agora, quando eu testei isso, não parecia funcionar. Cordas ainda perdidas
suas traduções. Cheguei até a melhorar o automaticamente
criou um breve layout do arquivo de configuração yaml [1], para
refletem exatamente o exemplo dado na seção Knowledge Base [2]
ligado acima.

Ainda assim, o Crowdin aparentemente, infelizmente, apenas substituiu o
strings, em vez de manter suas traduções e apenas remover o
aprovação. Estou fazendo errado?

String já teve tradução e aprovação (aprovação parece
invisível no arquivo .ts?)
[3]

A opção de atualização "update_as_unapproved" foi testada com curto e longo
yaml layout, ambos para o mesmo resultado
[4]

Depois de modificar a string (ou comentário), Crowdin agora mostra modificado
string sem tradução e aprovação
[5]

Crowdin Diff relata strings como "excluídas e adicionadas" não "mantidas, mas
perdeu a aprovação"
[6]

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub [7] ou silencie o
fio [8].

Links:

[1] https://github.com/Kebap/Mudlet/blob/crowdin-test/.crowdin.yml
[2]
https://support.crowdin.com/configuration-file/#changed -strings-update
[3]
https://user-images.githubusercontent.com/117238/45245753-12b3a300-b2fe-11e8-819a-fbc1cab389cd.png
[4]
https://user-images.githubusercontent.com/117238/45245828-632b0080-b2fe-11e8-8457-d16f53e62976.png
[5]
https://user-images.githubusercontent.com/117238/45245723-e7c94f00-b2fd-11e8-831d-14f3c0151aa8.png
[6]
https://user-images.githubusercontent.com/117238/45245651-843f2180-b2fd-11e8-8744-b431244e39e8.png
[7]
https://github.com/Mudlet/Mudlet/issues/1961#issuecomment -419583856
[8]
https://github.com/notifications/unsubscribe-auth/AA0k1tqzDWWwb2qGudFk9ENRg7Hm3D-Hks5uYvRcgaJpZM4WeaRq

Sim, o Qt IDE usa arquivos .ts. Certamente este não é um nicho. Alguma recomendação dos desenvolvedores do Crowdin?

O feedback do Qt foi inconclusivo:

(Kebap) Olá a todos! Alguém já usou um site de serviço baseado na web para lidar com traduções e tradutores? Usamos Crowdin e eles parecem não funcionar bem com o formato de arquivo Qt .ts. Eles parecem pensar que cada string modificada é uma nova string e excluirá traduções antigas. Veja o seguinte tópico para detalhes. Como podemos resolver isso? https://github.com/Mudlet/Mudlet/issues/1961
(frkleint) Kebap: Eu recomendaria postar na lista de discussão http://lists.qt-project.org/mailman/listinfo/localization
(Kebap) Parece que essa lista de discussão é sobre traduzir o próprio projeto Qt. No entanto, talvez existam outras pessoas construindo seu próprio projeto com Qt e traduzindo para outros idiomas?
(frkleint) Kebap: Sim, mas os mantenedores/pessoas certos irão lê-lo

Deixe-me verificar todos os detalhes, @Kebap. Eu tenho um "plano B" na minha cabeça, mas preciso testá-lo.

Tudo bem se você armazenar o texto de origem/traduções no elemento do arquivo .ts? No você pode ter um ID de string exclusivo, por exemplo

No momento, importamos/carregamos um arquivo mudlet.ts que contém o texto de origem para o CrowdIn e eles processam isso para produzir um mudlet_xx_YY.ts onde xx é o código de idioma de duas letras e YY é um código de país de duas letras. O mudlet.ts origem é, acredito, gerado/atualizado com o utilitário Qt lupdate que eu acho que é executado em nosso diretório de origem ./translations como lupdate -locations absolute ../src/mudlet.pro -ts ./mudlet.ts {at menos de um *nux OS}.

Existe uma alternativa, mas não sei se o CrowdIn pode funcionar assim em que fornecemos os arquivos individuais .ts (atualmente:

• mudlet_de_DE.ts
• mudlet_el_GR .ts`
• mudlet_en_GB.ts
• mudlet_es_ES.ts
• mudlet_fr_FR.ts
• mudlet_it_IT.ts
• mudlet_nl_NL.ts
• mudlet_pl_PL.ts
• mudlet_ru_RU.ts
• mudlet_zh_CN.ts
• mudlet_zn_TW.ts

) para o CrowdIn e faça com que ele/a equipe de tradução trabalhe neles. Isso significaria que os esforços de tradução existentes são mantidos dentro de cada arquivo .ts - é assim que o Qt prevê que a tradução seja feita - porque o lupdate atualizará cada arquivo de tradução individual com as alterações das fontes de código quando é executado, mas não descartará (a menos que explicitamente informado com o argumento -no-obsolete ) textos antigos que não aparecem mais nas fontes. A desvantagem disso é que não há um único arquivo de origem para todas as traduções que possam confundir/não funcionar com o sistema CrowdIn. A vantagem é que o #1963 imediato se torna um não problema, pois podemos gerar o arquivo mudlet_en_US.ts somente para plurais e incluí-lo no upload para o CrowdIn no lançamento/versão/qualquer alteração ...

Acho que o Crowdin requer um único arquivo como entrada. Lembro-me que durante a configuração não gostou de vários arquivos - ou seja, o problema era que o arquivo de entrada e saída era o mesmo.

Embora pudéssemos nomear os arquivos de entrada e saída de maneira diferente?

O Crowdin certamente pode lidar com vários arquivos de entrada, como em diferentes strings para traduzir. No entanto, no plano de SlySven, todos eles teriam conteúdos idênticos. Isso significaria que até mesmo a equipe de tradução polonesa veria todos os arquivos, incluindo mudlet_it_IT.ts e mudlet_ru_RU.ts, etc. Portanto, não continuamos nesse caminho muito mais e optamos por um arquivo de tradução central.

edit: A explicação para a criação de arquivos .ts está correta, mas o comando real usado é: lupdate -recursive .\src\ -ts .\translationsmudlet.ts

Não tenho certeza do que você quer dizer com Vadim, mas acho que Kebap está no mesmo caminho - poderíamos inserir todos os arquivos, mas como dizemos ao CrowdId que apenas o mudlet_ru_RU.ts do conjunto deve ser mostrado ao Tradutores de russo (Rússia) ?

@vadi2 Você está certo, é recomendável fazer upload de um único arquivo de origem, o Crowdin gerará os arquivos traduzidos.

Por favor, não carregue arquivos como mudlet_ru_RU.ts no projeto.

Provavelmente podemos marcar uma ligação para discutir isso? Entre em contato comigo em andriy(at)crowdin.com

Tenho uma ideia em mente que certamente funcionará, mas preciso saber se você ficará feliz com ela. O problema é que .ts não tem identificadores únicos para cada string - como em .po, arquivos onde msgid é fonte e identificador ao mesmo tempo, <source> é texto e identificador também (juntamente com os elementos <context> e <name> , cada string é considerada única e se você modificar <source> , a string será considerada como nova e você não poderá manter as traduções para modificações strings no resultado).

De qualquer forma, há uma solução/solução muito boa que eu gostaria de discutir/demonstrar para sua equipe;)

... e apenas alguns conteúdos seriam os mesmos - os textos das fontes - mas as traduções já feitas para cada localidade também são armazenadas em seu respectivo arquivo e estão presentes em cada ciclo de atualização-tradução seguinte.

Se eu entendi, o esquema de identificador de mensagem exclusivo também é permitido no sistema Qt, mas é mais difícil de trabalhar - e uma mudança no meio do projeto é uma tarefa não trivial (os dois sistemas são mutuamente exclusivos e você precisa de uma metodologia muito boa para chegar a identificadores significativos) - e parte do benefício do esquema existente é que as strings duplicadas são mescladas em uma única tradução comum, é apenas que a mudança de uma precisa que as outras também mudem se elas se destinam a ser o mesmo...

Quando traduzimos todas as strings em um idioma para 100% e, em seguida, editamos algumas em uma versão, ainda não seria muito fácil passar e adicioná-las novamente graças à TM?

Este problema só parece um problema real porque ainda não chegamos a 100%.

@vadi2 caso você queira ter a capacidade de traduzir automaticamente as strings recém-adicionadas com a ajuda do TM, você pode configurar esse fluxo de trabalho usando o recurso Advanced Workflows (acabei de habilitá-lo para sua conta)
https://support.crowdin.com/advanced-workflows/

Obrigado, apreciado :) vamos estudar isso.

@Kebap escreveu:

edit: A explicação para a criação de arquivos .ts está correta, mas o comando real usado é: lupdate -recursive .\src\ -ts .\translationsmudlet.ts

-recursive é o caso de argumento padrão e não é necessário - e também o -locations absolute para novos arquivos aparentemente ... :slightly_smiling_face: - Eu estava descobrindo isso enquanto verificava o efeito os problemas que lupdate ainda tem com literais de string brutas do C++ 11/14 { QTBUG , #1310} e se as strings estão sendo perdidas do arquivo mudlet.ts como resultado de confundi-lo .. . : franzindo a testa:

@Kebap Isso ainda é um problema?

Sim, embora não tão ruim quanto antes da mudança. Mas ainda é confuso, mesmo para os iniciados, como você pode ver pela questão vinculada de uma semana atrás.

Além disso, há um pouco de corrida atualmente, enquanto a maioria dos idiomas ainda não está perto de 100%, eles traduzirão strings mais rápido do que perdem traduções novamente?

Além disso, encontrei um problema que parece trazer de volta traduções excluídas. Atualmente não encontro como excluir uma tradução do Crowdin. Após a próxima atualização, ele será adicionado automaticamente novamente.

@Andrulko Você tem alguma atualização aqui? Você mencionou um plano B acima.

Além disso, por que Crowdin faz esse comportamento estranho na TM agora!? Veja a captura de tela abaixo para comparação.

Tudo o que foi alterado por nós aqui é h3 em a . Nenhuma outra etiqueta foi tocada. Agora o que aconteceu?

Você esperaria que os tradutores substituíssem cada {[=-lt;-=]}h2{[=-gt;-=]}{[=-lt;-=]}u{[=-gt;-=]} por <h2><u> ou melhor <0> manualmente?

Link para exemplo: https://crowdin.com/translate/mudlet/137/en-de
Cenário de exemplo:

Acho que é um bug na TM do Crowdin. Provavelmente é melhor relatar como um problema separado para eles.

Eu os informei aqui também: https://crowdin.com/contacts

Olá, já verificamos sua solicitação e respondemos ao seu e-mail. Por favor, deixe-nos saber se você tiver quaisquer outras perguntas!