Oi @mateus.m.luna, em continuação a esse tópico de março, configurei a data para d/m/Y no WP e está aparecendo m/d/Y no formulário:
Reli suas indicações e porém continuei sem achar uma solução. Pode porfa ajudar?
Obrigada!
Oi @tragnesia!
Como dito lá, o que esta configuração vai afetar é como os visitantes do site vão ver valores de data. Isso é diferente do que se configura no input porque pode incluir, inclusive datas em extenso (30 de Março de 2013). O valor do input é determinado de acordo com o idioma do seu navegador.
Independente da escolha dos inputs serem diferentes dos valores carregados…
Andei dando uma pesquisada aqui… mesmo que o navegador dele esteja com idioma Malay (estou supondo que seja esse, peço desculpas se estiver confundindo) ele vai estar vendo com o padrão americano porque precisamos colocar o “ms” na lista dos locales que carregamos em nossa biblioteca de tempo. Hoje a lista é restrita aos que sabemos que tiveram a tradução do plugin feita no repositório de traduções do WordPress:
Nós só carregamos alguns conjuntos porque este tipo de biblioteca pesa o plugin e ainda não chegamos à uma estratégia boa para carregar as dependências dela de forma mais dinâmica. De qualquer forma, vou adicionar para a próxima atualização este idioma visto que temos pelo menos relatos de usuários agora.
Pedi para duas pessoas testarem, idiomas de navegadores em PT e ES, e os dois como mm/dd/yyyy:
Que estranho… na teoria é uma informação que puxamos do navegador. Todo navegador tem uma função global navigator.language que retorna qual o idioma atual. No meu por exemplo navigator.language retorna pt-BR. Tanto pt quanto es puros deveriam funcionar também. Eu posso mandar uns scripts aqui para tentarmos debugar no console do navegador deles, mas não vai ser muito simples
Só para confirmar, a data no formulário aparece d/m por aê?
Obrigada!
Sim…
Quer que eu envie os passos aqui pra testarmos o navegador deles?
1 curtida
oi, sim, agradeço!
Eles vão precisar primeiro abrir o console do navegador deles. É o mesmo passo que descrevemos aqui. De preferência o façam com uma aba onde o Tainacan ou o formulário de submissão esteja aberto pra confirmarmos que a Moment.js está carregada.
Com o cursor dentro do console, peça para digitarem e dar enter na seguinte linha:
navigator.language
Isto deve retornar “es” ou “pt”, provavelmente. Estando correto, peça para colarem de uma vez e dar enter nas seguintes linhas:
let locale = navigator.language;
moment.locale(locale);
let localeData = moment.localeData();
this.dateFormat = localeData.longDateFormat('L')
No meu aqui é retornada a seguinte: “DD/MM/YYYY”
Me diga se com eles ocorre da mesma forma, ok?
Oi Mateus, agradeço, vou repassar.
Mas a questão não se resolve com sua orientação: o formulário será publicado para pessoas que poderão ter seus navegadores com idioma EN, porém de países com padrão ‘dd/mm’, o que pode acarretar em um erro.
Mais alguém tem esse problema? Não seria possível se referenciar ao idioma do site em si?
Obrigada!
O formulário respeitará o idioma que o usuário optou no seu navegador, não faz sentido?
Em teoria sim: uma pessoa no US/Canadá veria o formulário com m/d.
Porém não nesse caso: os campos do formulário estão em inglês e bengali (optamos por garantir os termos corretos nesses dois idiomas ao invés de usar plugin de GTradutor) e é voltado para pessoas em Bangladesh (com o formato d/m), com provável uso de navegadores em inglês (meu colega na Malasya que suscitou essa questão, quando for dia lá checo se o navegador dele está em inglês).
Agradeço a paciência e as informações!
Lidar com internacionalização é sempre desafiador. Por um lado, é importante reforçar que o próprio WordPress não tem uma saída oficial ainda pra isso. Eles dizem que a Fase 4 do projeto Gutenberg será sobre isso mas tem sido cada vez mais adiado pelo foco que tem se dado à Fase 3. O fato de que ele não te permite configurar idiomas diferentes sem plugins (e até a questão da hora) reforça isso.
Mas acho que é preciso deixar claro que aquela configuração que você está achando que seria o “idioma do site” aqui não serve pra esse contexto. Ela diz respeito apenas à formatação de datas da exibição delas (inclusive em posts, avisos do sistema, etc).
Por que não serve: porque ela permite de tudo. Você pode colocar dia, hora, data em extenso, data em siglas… por outro lado, a informação que este campo de entrada precisa saber é: como eu vou receber um dia, um mês e um ano e como eu vou transformar eles em um valor que o banco de dados entende (yyyy-mm-dd).
Portanto, nós não sabemos que você quer que as datas sejam entradas em d/m/Y, isso é apenas um sigla que o WordPress usa para exibir datas. O que nós precisamos saber é: você vai entrar a data em dd/mm/yyyy, mm/dd/yyyy, yyyy-mm-dd, etc… Entende? São realmente dados diferentes. Acho que é válido sim pensarmos em uma opção para se forçar este valor independente do navegador, mas eu não sei bem nem por onde começar a listar as opções que deveriam ser oferecidas e também acho que a alternativa do navegador tem pelo menos em termos de intenção, ser o mais próxima possível da realidade do usuário, sem forçar um padrão. Bom, quando funciona, é claro, temos que entender o que está pegando com estes casos que você trouxe
1 curtida
Também acho que isso vai se resolver melhor se implementarmos um datepicker de fato, com calendário e tals pra este tipo de metadado. É algo que já foi feito antes mas justamente pela diversidade de cenários que existia voltamos atrás.
1 curtida