Com as etiquetas: pt_PT Mostrar/esconder comentários | Atalhos de teclado

  • Álvaro Góis 23 Nov 2015, às 20:09 Permalink |
    Etiquetas: , editores, , pt_PT, , 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.

  • PL Monteiro 9 Apr 2013, às 15:33 Permalink |
    Etiquetas: , pt_PT,   

    Olá. Tenho dado assistência na tradução de alguns temas e plugins, coisa pouca, mas num tema em que a colaboração já tem uns anos, surgiu a questão de passar ao AO90 ou não passar. O vosso glossário aqui diz “pós-Acordo” e data de Junho. Numa outra entrada, talvez até no fórum WordPress.org, datada de Agosto, o Ze Fontainhas refere-se a estarem ainda em “pré-Acordo.” Recordo-me que há já bastante tempo, mais de um ano provavelmente, foi aqui discutido ficar em “pré.” Não consigo encontrar nada mais recente que me indique a posição oficial da Comunidade nesta matéria.

    Portanto, pergunto a todos os que estão a fazer traduções pt_PT: estão já pós-acordo ou estão a manter as traduções em pré-acordo? Obrigado.

     
    • Zé Fontainhas 9 Abr 2013, às 15:57 Permalink | Inicie a sessão para responder

      Boa pergunta…
    • Álvaro Góis 9 Abr 2013, às 16:10 Permalink | Inicie a sessão para responder

      Como a discussão original foi difícil (e, claro, sem consenso), nunca se passou das palavras aos atos. Pessoalmente sou contra o AO90, mas não posso escamotear o facto de estar em vigor (sim, é discutível, mas não creio que este seja o fórum indicado para isso…) e de ter clientes que querem/precisam trabalhar com o AO90. Portanto, a minha opção foi traduzir seguindo o AO90. E tento aplicá-lo sempre que posso (e consigo), e com muito esforço. Mas a verdade é que no repositório do pt_PT ainda não aplicámos. Uma possibilidade para quem quer manter-se fiel à ortografia pré-1990 seria qualquer coisa como o que cheguei a propor para o português informal, um plugin que fizesse a substituição dos ficheiros de linguagem. É claro que teoricamente é fácil, mas na prática é preciso: 1) quem desenvolva uma coisa dessas; 2) quem esteja disposto a gerir os ficheiros de língua nas versões alternativas. E não é nada simples mantê-los sincronizados, como a versão informal bem tem demonstrado. E com o ritmo de atualizações do WordPress, revela-se uma tarefa muito complicada. Ainda há uns dias andámos a celebrar o 3.5 e já está aí a beta do 3.6. É frenético isto.
      • Zé Fontainhas 9 Abr 2013, às 16:39 Permalink | Inicie a sessão para responder

        3.7?
      • PL Monteiro 9 Abr 2013, às 17:05 Permalink | Inicie a sessão para responder

        Obrigado Zé. Obrigado Álvaro. Um plugin de facto seria um problema porque teria de manter um glossário alternativo não só para o core como para outros plugins e temas. Parece-me undoable. Mas está a passar-se o que disse ao meu colega: instituições e empresas têm de usar o AO90, os utilizadores individuais fazem à sua vontade. Por mim, embora use versões en-US do software, por vezes escrevo em pt-PT e passei para o AO90. Não é que goste muito (a palavra que mais me fere a vista é “exato”), mas a ideia é de que com o tempo acabarei por me habituar, e como faço verificação ortográfica em tudo, qualquer engano o software corrige. Fico então informado de que o core ainda utiliza pré-AO, mas a manutenção de sites para clientes está a adotar o AO. Da minha parte vou recomendar ao colega a passagem para o AO. Se estivesse a ver ação decisiva por parte dos críticos, anteciparia um roll-back. Mas na política à portuguesa discute-se durante anos sem que dos debates surjam resultados concretos. Isto é um tanto tramado, pois como sabem o Brasil adiou a implementação para 2016, e os outros países de língua oficial (em África e Timor) usam a nossa ortografia tanto quanto sei. Parece-me também que estão a tentar manter ambas as versões? — uhmm — Já não sei para onde me virar. O WPLANG não pode ser alterado. Para Firefox/Thunderbird/OpenOffice/LibreOffice dois dicionários são mantidos, porque são sub-produto de investigação linguística (da Universidade do Minho), mas mesmo assim têm de ter a especificação única pt-PT ou corrompem os dados de configuração. Pode ser um bom bocado mais fácil para todos passar para o AO90, e depois se os políticos decidirem um roll-back, uma atualização e escreve por cima. Fica a sugestão.
        • Zé Fontainhas 9 Abr 2013, às 17:09 Permalink | Inicie a sessão para responder

          Vamos não complicar, boa? Passa-se para o AO e pronto (apesar dos vómitos que me provoca). A minha sugestão é que se comece a fazer já uma passagem pelo que está (futura 3.6), pelo menos naquilo que pode ser feito de maneira mais ‘maciça’.
          • Álvaro Góis 9 Abr 2013, às 17:13 Permalink | Inicie a sessão para responder

            +1 Como é que se faz a passagem? Sugestões?
            • Zé Fontainhas 9 Abr 2013, às 17:14 Permalink | Inicie a sessão para responder

              Podemos começar por ir directos ao .po com o texto, por exemplo.
            • PL Monteiro 9 Abr 2013, às 17:25 Permalink | Inicie a sessão para responder

              O PoEdit pode vir a ter compatibilidade com verificação ortográfica na v1.6. Depois depende do dicionário que for escolhido. Até lá em temas e plugins, que nas coisas mais complicadas têm 600 a 800 strings que foi o máximo que encontrei, pode exportar-se o catálogo como HTML e depois ver a ortografia com um processador de texto, que apresenta a tabela na mesma ordem que o PoEdit. Inspecionei um tema com 600 strings e não havia grandes modificações. Até detetei alguns typos. É mais a minúcia de rever 600 strings. Não faço ideia quantas strings vocês têm no core do WordPress.
              • Zé Fontainhas 9 Abr 2013, às 17:34 Permalink | Inicie a sessão para responder

                10.000, mais milhar, menos milhar 🙂
                • PL Monteiro 9 Abr 2013, às 18:09 Permalink | Inicie a sessão para responder

                  Geez… O PoEdit permite verificação ortográfica nalgumas plataformas como o Mac e o Linux. Nestas não deve ser muito difícil de fazer. Basta percorrer a tabela porque como referi, as alterações ortográficas afetam relativamente poucas entradas. Em Windows, pelo método do intermediário HTML, 10 000 strings resultarão certamente em verificação não muito cuidadosa em grandes porções. Terias que supervisionar a coisa. Primeiros, pegar no po de 10000 e como ficheiro de texto, dividi-lo em 20 ficheiros po de 500 strings cada. Passá-lo a 20 voluntários, ou 5 voluntários em 4 dias. Depois fazer o merge de texto de todos os ficheiros po. Penso que os ficheiros po podem ser abertos como texto simples, embora convenha verificar o encoding character set.
                • Zé Fontainhas 9 Abr 2013, às 23:37 Permalink | Inicie a sessão para responder

                  Terias que supervisionar a coisa
                  Alto e pára o baile: “Teria”? Não era “teríamos” que querias dizer? 🙂
              • PL Monteiro 10 Abr 2013, às 16:41 Permalink | Inicie a sessão para responder

                Pensei um pouco nisso durante a noite e o trabalho de tradução é um bocado ingrato. Começando de raiz tem-se um montão de strings pela frente e o progresso é lento. Depois parece que nunca terá fim. Isto acontece principalmente quando se começa pois se se tem uma versão completa, updates posteriores podem adicionar novas strings mas não são em número avassalador. Portanto estava a meditar nas vantagens psicológicas de distribuir o trabalho por voluntários (apontemos para 10), dar uma porção facilmente digerível em 2 ou 3 horas que encaixam facilmente num buraquito de um dia normal de trabalho, e uma meta acessível, específica e tangível em 2 dias. Podíamos experimentar isto para a verificação ortográfica da Novilíngua e com lições aprendidas, aplicar a mesma ideia para produzir a tradução completa para a versão 3.6. O processo tem de ser centralizado no início e no fim. É necessário alguém (e só um pode segurar a faca) que corte o bolo e dê a respetiva fatia a cada participante. Habitantes de Mac e Linux podem receber um pouco mais. Depois é fazer o merge dos ficheiros. Abrindo num editor de texto, o ficheiro po tem efetivamente um cabeçalho com a indicação (que acho que até fui eu que pus) [quote]”X-Poedit-SourceCharset: utf-8\n”[/quote] mas reparem abaixo que faz, sem mais nada, acentos e “ç” c’s cedilhados. [quote]#: includes/theme-setup.php:278 msgid “” “The footer widget area. Leave empty to disable. Set the number of columns to ” “display at the theme’s Display Options page.” msgstr “” “Área do widget do rodapé. Deixar em branco para desactivar. Especifique o ” “número de colunas a mostar na página de opções de Mostrar do tema.”[/quote] Parece-me que se houvesse mais qualquer coisa o editor de texto que uso também para código, mo mostraria. Também me passou pela cabeça que isto podia ser feito numa espécie de meet-up de voz pelo Skype, mas não sei se seria vantajoso porque à parte recordar-mo-nos do standard para alguns termos, seria uma distração numa tarefa que me parece pretty straightforward.
              • PL Monteiro 10 Abr 2013, às 17:06 Permalink | Inicie a sessão para responder

                Não consegui pôr as quotes corretamente, peço desculpa. Fica a sugestão.
          • PL Monteiro 9 Abr 2013, às 17:14 Permalink | Inicie a sessão para responder

            Parece-me mais fácil retroverter as mudanças mais tarde do que tentar patinar em duas faixas de rodagem.
          • Álvaro Góis 10 Abr 2013, às 17:10 Permalink | Inicie a sessão para responder

            E não dá para pegar no bicho e mandá-lo para o Lince?
            • Álvaro Góis 10 Abr 2013, às 17:24 Permalink | Inicie a sessão para responder

              Acabei de fazer isso com o admin-pt_PT.po. Abri com um editor de texto, guardei como .txt, aticei-lhe o Lince, e fiz o percurso inverso com o ficheiro que resultou. O meu PoEdit identificou um erro no cabeçalho mas o ficheiro parece estar operacional. E actualizado. A minha sugestão era que replicassem para chegarmos a uma conclusão. (Claro que este procedimento não elimina os erros na tradução, mas isso não tem a ver com o AO90, é outro projeto.)
              • Zé Fontainhas 10 Abr 2013, às 18:13 Permalink | Inicie a sessão para responder

                Criar artigo no wp-portugal (e por no twitter, fb, e tal) a explicar o que se vai passar, para toda a gente ficar a saber e poder opinar (deixar os comentários fechados e adicionar uma nota que a discussão é neste P2)
              • PL Monteiro 10 Abr 2013, às 19:02 Permalink | Inicie a sessão para responder

                Boa dica com o Lince, Álvaro. À cautela para evitar erros no cabeçalho, este pode ser removido no ficheiro txt e depois colado novamente. Infelizmente não posso corroborar o que fizeste porque neste momento não estou a administrar nenhum site pt_PT. Os utilizadores convém terem aviso prévio, sim. E como empresa o WordPress tem de passar para o AO, assim como já aconteceu com a Mozilla, e como o Álvaro disse logo no inicio deste thread individualmente nenhum de nós gosta da nova ortografia, mas os clientes empresariais e institucionais têm de o adotar. Parece-me que é fácil antecipar como será o feedback. A questão a sublinhar é a de que “There can be only one!” Ou os críticos do AO tomam algum tipo de ação decisiva, ou podemos confiar na certeza que com o tempo nos habituamos. Mas aviso já que se prepara uma tempestade na CPLP. O Brasil, adiou, segundo a notícia do Sol (jornal) porque a língua portuguesa pode ser simplificada AINDA MAIS do que este acordo prevê, e os outros países da língua nem estão a fazer a transição. Da nossa parte no entanto temos que decidir, e quanto menos a coisa se arrastar menos dolorosa é. Da minha parte voto que se adote o AO e depois se os políticos voltarem a trás, faz-se a retroversão. Mas com a situação política do país, esta não é uma questão legislativa premente e é improvável que o decreto-lei (ou o que foi) que tornou o AO oficial venha a ser anulado.
  • PL Monteiro 6 Sep 2011, às 20:32 Permalink |
    Etiquetas: pt_PT,   

    Não sei bem como fazer o interface com vocês, mas podia talvez colaborar mais, com vista a ajudar no desenvolvimento de um standard pt_PT 1) práctico, e 2) sem ferir o ouvido do português europeu. Exemplos no glossário: “shuffle,” baralhar, misturar; “log,” registo; “hosting” hospedagem; “frame,” moldura (a não ser que se trate de video); “sticky,” prioritário.

    Estes são alguns que talvez se possa melhorar. Por outro lado sou da opinião de que termos como link ou upload, não tendo uma tradução menos do que muito forçada deveriam ser conservados com o spelling inglês.

    Devo dar uma volta à lista, para ver se encontro mais?

     
    • Paulo Faustino 6 Set 2011, às 20:40 Permalink | Inicie a sessão para responder

      Aqui vão as minhas sugestões PL Monteiro: “shuffle,” – misturar “log,” – registo “hosting” – Alojamento “frame,” – moldura “sticky,” – destaque/prioritário
      • PL Monteiro 7 Set 2011, às 6:04 Permalink | Inicie a sessão para responder

        Obrigado. É sempre bom conferir estas coisas. O termo “alojamento” parece ser o cânone, e por esta altura já haverá um certo hábito. Sempre preferi “hospedagem” porque se disser a alguém “o site está alojado num servidor holandês” (digamos) o que a frase me parece dizer é que o site está em armazenamento estático algures na Holanda. Já dizendo “o site está hospedado num servidor holandês,” parece-me mais próximo do que acontece realmente. É uma diferença de pormenor. E a minha justificação pode nem ser a melhor. Just sayin’.
        • Celso Azevedo 7 Set 2011, às 12:36 Permalink | Inicie a sessão para responder

          Penso que o melhor é usar o termo “alojamento” já que “hospedagem”, tal como o Paulo Faustino disse, não é muito usado em Portugal. Alojar e hospedar é basicamente a mesma coisa, é “guardar” algo, por isso sou a favor do termo Alojamento pois é o mais utilizado em Portugal.
    • Paulo Faustino 7 Set 2011, às 11:47 Permalink | Inicie a sessão para responder

      O problema é que em Portugal ninguém usa o termo “hospedagem”, excepto se estivermos a falar da área de “hotelaria” em que uma pessoa fica “hospedada” num hotel. Em Portugal o termo é Alojamento ou Alojamento Web. No Brasil sim, é usada a terminologia “Hospedagem” ou “Hospedagem Web”. Daí que talvez seja importante manter o pt_PT de acordo com a língua 🙂 Abraços
    • Rui Cruz 7 Set 2011, às 13:32 Permalink | Inicie a sessão para responder

      “hosting” – alojamento web. Apenas alojamento fica… vago. Ruji
    • PL Monteiro 7 Set 2011, às 18:24 Permalink | Inicie a sessão para responder

      Mais duas que não têm na lista: “fade,” desvanecer (embora o uso do termo original é tão comum que talvez não se justifique tradução); “follower,” fan (não consigo encontrar melhor, a alternativa é seguidor que não soa bem).
    • Paulo Faustino 7 Set 2011, às 18:57 Permalink | Inicie a sessão para responder

      Follower é mesmos seguidor 😛 Não me parece que traduzir para “fan” seja boa onda, até porque “fan” é um termo inglês inclusive.
    • Paulo Faustino 7 Set 2011, às 19:36 Permalink | Inicie a sessão para responder

      Follow = Seguir Follower = Seguidor Parece-me perfeito 😛 Pelo menos foi a linguagem que o twitter adoptou na sua versão portuguesa e é bastante mainstream nos dias de hoje 😉
    • Lopo 26 Set 2011, às 19:49 Permalink | Inicie a sessão para responder

      De referência de Português de Portugal tenho este link da concorrência: http://localize.drupal.org/node/664 Poder-se-ia fazer algo semelhante para o WordPress de Portugal.
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