Actualizações de Novembro, 2015 Mostrar/esconder comentários | Atalhos de teclado

  • Álvaro Góis 23 Nov 2015, às 20:09 Permalink |
    Etiquetas: , editores, , , , validadores   

    Gostaria de mobilizar algumas pessoas que conheçam e possam contribuir para o GlotPress para conseguirmos resolver um problema que estamos a ter com as traduções portuguesas. Nos últimos meses houve duas alterações muito significativas na forma de gestão das traduções no WordPress. Por um lado, o WordPress passou a considerar variantes da língua para o mesmo locale, abrindo assim a possibilidade, p.e., a versões formais e informais. Mas, e no nosso caso isso é significativo, também a variantes ortográficas, como a do A090. Por outro lado, a integração de temas e plugins no GlotPress oficial do WordPress.org veio reforçar a necessidade de consolidação de termos e de minorar a mais que provável confusão que se vai instalando.

    Quais são as opções neste momento? A primeira seria ter uma versão AO90 para o WordPress (core, temas e plugins). O problema é que isso iria criar necessariamente problemas de consolidação de termos e de desfasamento. Se é possível criar uma versão AO90 a partir da versão oficial (usando ferramentas offline), e foi isso que fizemos com o PT Variants, a verdade é que não existe ferramenta que faça o caminho inverso. Ou seja, quando tivermos o WordPress pt_PT também a obedecer ao AO90, serão duas versões autónomas, para as quais poderão existir contribuidores diferentes com formulações diferentes. O que é um problema sério, tanto para o resultado final como para a gestão de traduções, de editores e de validadores das traduções. A verdade é que, assim como estamos, com apenas uma versão, já existe um desfasamento tremendo entre as traduções do core, apps, temas e plugins, muitos deles com termos completamente inadequados e, em muitos casos, absurdos.

    Há uns meses comentei num ticket do GlotPress sobre as vantagens de ter alguma forma de integração entre a versão por omissão e variantes no fluxo do GlotPress. Muitas variantes têm apenas ligeiras diferenças face à versão principal, pelo que uma faculdade de edição em paralelo, com cópia da versão principal, minoraria os erros e facilitaria muito a manutenção das traduções. Acontece que, e com alguma naturalidade (consta que não haverá muitos países com variantes suficientemente mobilizados), este ticket não teve tracção suficiente para que houvesse alguma implementação que, admito, não seja simples.

    Uma outra forma de lidar com a questão seria ter em paralelo no GlotPress a versão AO90, mas apenas de leitura. I.e., o core estaria disponível também no AO90. Esta versão poderia ser implementada offline, como o PT Variants, e carregada no GlotPress a cada novo lançamento. Mas não é possível bloquear a edição, pelo que teríamos o mesmo problema de consolidação quando começasse a haver edição em paralelo.

    Não tenho, de momento, uma solução para o problema. Comecei este comentário a tentar arregimentar contribuidores, mas não será fácil. Portanto, o meu objectivo centra-se, pelo menos, em tentar espoletar opiniões diversas e formas de atacarmos isto.

    Não sendo justo impor-se uma norma ortográfica aos utilizadores, e em especial impor-se uma nova norma ortográfica a quem usa a antiga, também é verdade que, havendo essa possibilidade, não parece correcto que os novos utilizadores não possam usar a norma ortográfica advinda do AO90. A disponibilização do PT Variants foi uma forma de atenuar essa falha, numa altura em que o WordPress ainda não reconhecia variantes. Mas agora que reconhece, como é que vamos lidar com isto?

     
    • Álvaro Góis 23 Nov 2015, às 22:54 Permalink | Inicie a sessão para responder

      Entretanto, o GlotPress está prestes a virar plugin: https://wordpress.org/plugins/glotpress/

      Isso talvez facilite algumas ideias sobre como hackar a coisa…

    • José Freitas 24 Nov 2015, às 14:04 Permalink | Inicie a sessão para responder

      Embora me prepare para engolir um sapo de um tamanho de um elefante africano, acho que a comunidade deve debater a transição da ‘versão oficial’ para o AO90.

      O período de transição ou já terminou ou termina dentro de meses – em Setembro de 2016 – e não há sinais de qualquer mudança na política actual.
      De resto, creio que a haver alterações estas não irão significar um regresso ao pré-AO90 mas sim a correcção de incongruências do acordo.
      Por muito que me custe reconhecer, podemos estar numa acção de resistência activa mas que não passará de uma luta quixotesca.

      Também não tenho uma solução para este problema.

      Tenho as seguintes sugestões:

      • Debater a mudança da versão oficial do WordPress pt_PT para o AO90 a partir da versão 4.5
      • Se for decidido que deveremos manter o pré-AO90 e for viável a existência de variantes (pré e AO90), as duas versões devem ter os mesmos validadores para manter a consistência (sim, sei qual é a quantidade de trabalho em perspectiva)
      • Implementar no WP Portugal um glossário de termos oficiais e que, dentro do possível, quem traduz plugins e temas deverá fazer por respeitar. Neste aspecto há já algum trabalho feito pelo Pedro Mendonça, do ponto de vista linguístico e técnico, tendo o Carlos Silva já dado alguns passos numa outra opção técnica. Não podemos obrigar ninguém que traduz plugins a respeitar esse glossário mas podemos sensibilizar as pessoas a seguirem essa via.
    • Pedro Mendonça 24 Nov 2015, às 14:16 Permalink | Inicie a sessão para responder

      Parece-me que a necessidade de adoptar o AO90 dependerá do tipo de site. Provavelmente o site de um serviço público terá muito maior necessidade de cumprir com as novas normas do que um pequeno site em que o autor continue a preferir não mudar.
      Considerando o que o Álvaro disse sobre a facilidade de conversão dos textos pré-AO90, sendo que o inverso não é possível, continua a parecer-me boa ideia manter a versão original em pré-AO90, com conversão automatizada a cada versão do core.

      Desde que entraram os plugins e temas para a plataforma de tradução que a confusão aumentou, por um lado é bom para a consolidação, por outro é impossível que todos os plugins mantenham traduções activas sem que aumente também a quantidade de validadores. Alguns plugins / temas tinham já uma comunidade de tradutores, faria algum sentido que as permissões de edição e validação não fossem apenas genéricas por Language Team, mas também por sub-projectos, por plugins, core, etc. Isto seria uma boa opção principalmente para a gestão do core.

      • Álvaro Góis 24 Nov 2015, às 14:20 Permalink | Inicie a sessão para responder

        @pedro-mendonca: as permissões de validação são por subprojecto. As permissões de edição são globais, existem para todos os utilizadores registados, para qualquer projecto.

        • Pedro Mendonça 24 Nov 2015, às 14:24 Permalink | Inicie a sessão para responder

          Não sabia, isso torna tudo menos assustador 🙂

          • Álvaro Góis 24 Nov 2015, às 14:36 Permalink | Inicie a sessão para responder

            No caso do AO90 não. Porque se se pudesse limitar as permissões de edição na versão AO90 (core), nós poderíamos ter essa variante em paralelo, que só seria actualizada via importação da versão oficial depois das respectivas conversões. Ou seja, temas e plugins poderiam ter versões AO90 abertas, consoante os editores interessados, o core manteria a consolidação de termos e expressões entre ambas as variantes, pois não haveria editores a contribuírem apenas para uma das versões.

            Mas como isso não é possível, penso que as opções passarão por: 1. tornar isso possível com o contributo dos nossos devs 😉 e/ou 2. abrir a variante mesmo assim e esperar pelo trabalho que se avizinha.

            Só uma coisa é que é certa: depois de criada, não há como voltar atrás.

            PS: há uma 3.ª hipótese, que é o @lightningspirit fazer a tal ferramenta que é o Lince invertido, que passa de AO90 para português 😛 Aí poderíamos estar descansados, contribuiríamos todos para uma única versão e a outra era mantida com uma conversão automática.

            PS2: há uma 4.ª hipótese… desenvolver-se um addon para o GlotPress que faça a actualização automática da versão AO90 a partir do português, usando as regras actuais de conversão. No fundo aquilo é uma lista fechada, com regras (estúpidas, algumas, é certo) mais ou menos claras e estabelecidas.

            • Pedro Mendonça 24 Nov 2015, às 14:44 Permalink | Inicie a sessão para responder

              Em todo o caso, mesmo que não se possa fechar a edição da versão que será traduzida automaticamente, na criação da variante pode ficar documentado que é uma tradução automática e que será reposta a cada nova versão. Com esta informação, os tradutores saberão que não valerá a pena investir na tradução dessa mesma variante.

  • Vitor Carvalho 20 Feb 2015, às 1:35 Permalink |
    Etiquetas: , , ,   

    Olá pessoal (desde há algum tempo),

    Estou a traduzir a última versão do polylang e deparei-me com uma palavra fixe “string”.
    Como é que temos andado a traduzir “string” para PT?

    Contexto: “Use this to remove unused strings from database, for example after a plugin has been uninstalled.”

     
    • Álvaro Góis 20 Fev 2015, às 9:05 Permalink | Inicie a sessão para responder

      Eu diria “frase”, embora string não remeta apenas para frase, pode ser uma palavra.

      Por outro lado, frase também não se limita a uma sequência de palavras, há áreas em que é aplicada para designar a ligação de elementos num conceito, sem significar exactamente palavras ou sequência de palavras – em arquitectura, em música, etc.

      Posto isto, e há falta de melhor, “frases” pode ser a solução mais compreensível, dado o contexto.

    • miguelcortereal 20 Fev 2015, às 11:29 Permalink | Inicie a sessão para responder

      Vitor (@lightningspirit), para este caso em concreto do Polylang sendo eu também um utilizador do dito plugin, a minha opinião é que simplesmente nem seja traduzido e fique “string”. Toda a gente minimamente ligada ao desenvolvimento (“Developers”) sabe o que é uma “string” e aplicando “frase” pode reduzir o contexto ficando assim a tradução pior.
      Exemplo típico de uma string de tradução do Polylang:
      %%sitename%% %%page%% %%sep%% %%sitedesc%%

    • Vitor Carvalho 22 Fev 2015, às 16:09 Permalink | Inicie a sessão para responder

      String será 🙂

    • Luís Rodrigues 17 Mai 2015, às 11:11 Permalink | Inicie a sessão para responder

      Já venho tarde para responder, mas do que me lembro dos livros de programação em português, a tradução aceite era “cadeia (de caracteres)”.

  • hcarvalho 21 Nov 2012, às 0:48 Permalink |
    Etiquetas:   

    Boas pessoal , peço desculpa por incomodar , existe alguma óptima alternativa ao plugin WPML ?!

     
  • Zé Fontainhas 4 Jun 2012, às 9:29 Permalink |
    Etiquetas:   

    É oficial: WordCamp Lisboa 2012

    Não posso insistir que chegue que é preciso muita divulgação disto. Por favor chateiem as vossas redes todas, até já não vos poderem ouvir 🙂 (e não esquecer as hashtags, #wclx e #wclx12, não é sr. @nuno-morgadinho?)

    https://twitter.com/wordcamplx/status/209576388389371904

     
c
compor novo artigo
j
próximo artigo/próximo comentário
k
artigo anterior/comentário anterior
r
responder
e
editar
o
mostrar/esconder comentários
t
voltar ao topo
l
iniciar a sessão
h
mostrar/esconder ajuda
shift + esc
cancelar