-
-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat: Adiciona lógica para ter mais de uma linguagem #140
Conversation
✅ Deploy Preview for diciotech ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pooooooooo, isso tá bem bacana!!!! Desculpa a demora pro review 😭 Se tu conseguir atualizar a branch tá a gente dá um merge 🫰🏻
Acho que vale o merge dessa PR e num próximo a estilização do seletor de línguas. Inclusive acho que seria legal ficar ali ao lado do botão de mudar o tema como um dropdown aparecendo somente as iniciais da língua atual e as outras dentro (EN-US, PT-BR). Assim ia ficar com o tamanho parecido com o de selecionar temas. |
Eu fiquei com preguiça de estilizar em css puro, mas vou fazer essas atualizações |
@azevgabriel se for facilitar, você pode apenas atualizar a branch e criamos uma nova issue pra essas estilizações, o que acha? |
Vou tentar adiantar essa semana! Pode deixar, muito bastante coisa no projeto. |
Fiquei pensando agora, a ideia do projeto é ser o mais puro em html/css/javascript possível @levxyca? Se não, a gente podia de repente adicionar mais alguma tecnologia que pudesse facilitar. Eu sei que o Astro tem suporte a internacionalização e o Jekyll tem um plugin pra isso. É que eu fui olhar, por exemplo, essa PR adiciona tradução dos cards, mas o resto dos textos na interface não são traduzidos. E eu não sei o quão chato vai ser implementar isso depois. |
@george-gca a ideia é termos um projeto que seja acessível para as pessoas contribuidoras também, até então, não sentiamos necessidade de adicionar outras tecnologias, mas a partir do momento que entendermos que vai facilitar, não vejo o porque não! O único ponto importante é sempre levarmos em consideração que quando adicionarmos alguma tecnologia nova, precisamos como requisito adicionar uma boa documentação em conjunto para deixar um ambiente amigável para outras pessoas contribuirem também. Podemos estudar essa possibilidade de uma nova tecnologia e ver como isso vai impactar! Melhorias são sempre bem vindas 🚀 |
Então, perguntei isso porque atualmente eu sou mantenedor num template de site acadêmico feito usando jekyll. Apesar do template ser muito bom, eu queria fazer meu site pessoal com suporte a múltiplos idiomas, então criei um fork do template com suporte a vários idiomas que mantenho sempre bem atualizado com o repositório original. O suporte a múltiplos idiomas foi feito usando um plugin do Se quiseres, eu posso tentar fazer uma versão do site com |
Perfeito @george-gca, acho uma boa! |
Votem sobre isso em #243. |
@levxyca @george-gca Amigos, vocês se decidiram? Posso resolver os conflitos disso ou vai ter outra PR para implementar os idiomas? |
@azevgabriel eu criei a #217 como uma alternativa. Dá uma olhada no que tu achas. Eu criei ela porque eu acho que não é complicado de manter e também porque faltou na tua PR traduzir outros elementos pra inglês, como o resto da interface e das informações nas tags Mas antes de tudo acho que vale votar na #243 pra gente decidir se adicionar suporte a múltiplos idiomas é uma prioridade ou não. |
Isso, vamos aguardar mais um pouquinho pra entender melhor essa questão |
Belezura, já votei lá. Por um lado eu acho massa demais usar lib, plugins e tals. @levxyca Vai de você decidir qual é a intenção do projeto, manter essa cara raiz e criar tudo do zero praticamente ou optar por soluções pré estabelecidas. |
Então, ela falou ali em cima que desde que bem documentado e não acrescente muita complexidade ela topa adicionar novas ferramentas. Dá uma olhada na #217 @azevgabriel, vê o que tu achas. Lá eu expliquei melhor o porque eu acho que vale a pena adicionar o Jekyll nesse caso. A mudança no código atual html e javascript é pequena, e tem a facilidade de adicionar novos idiomas só mexendo em poucos arquivos. No commit aparece como novo arquivo porque eu renomeei os arquivos pra Inclusive usando o Jekyll a gente consegue mandar ele lidar com o sass e gerar o css. Isso resolve o problema de pessoas adicionarem mudanças só no css e não no sass. E também dá pra incluir nele pra gente juntar o json em um só como tu fizeste com o Python, então já fica tudo integrado em um único processo de build. Mas eu não adicionei essa parte nem a documentação ainda, que eu não vou investir tempo nisso até que estejam de acordo. |
Exatamente isso! Meu objetivo principal é que seja um projeto amigável para outras pessoas contribuirem, então nada impede de usarmos ferramentas para nos ajudar no desenvolvimento 🚀 desde tudo esteja sempre bem documentado, é tranquilo! O projeto é feito desse jeito mais "raiz" pois ele começou bem pequeninho e era o mais simples no começo, mas nada nos impede de melhorar isso!!! |
Então vou fazer o seguinte, vou pegar a versão mais atual do código e gerar de novo com o Jekyll traduzindo (ignorando a documentação e os termos novos que eu não vou traduzir agora) e incluindo a parte do sass e da #217 pra mostrar como ficaria. |
Implementei na #267. |
@george-gca estava pensando aqui antes de olhar tua implementação, como vamos ter, além da revisão e compreensão, criar toda a documentação pra essa mudança caso ela ocorra, será que não vale seguirmos com essa PR para termos essa feature até o momento que tivermos de fato essa alteração para o Jekyll, que acredito que será uma grande mudança 🤔 |
Aproveitem minhas férias, tiro dia 20. Aí consigo já dar um tapa nessa PR. |
As 2 soluções são bem diferentes do ponto de vista de implementação. Então supondo que a minha PR entrasse depois dessa, tudo que foi feito nessa teria que ser desfeito pra minha entrar, criando um problema de merge que pode ser evitado, já que as 2 são redundantes. Nessa é criado 1 arquivo pra ter as traduções das tags, além de toda a lógica pra mudança de idioma feita em js. Nada disso faz sentido ter no meu código, já que o jekyll lida com isso pra mim. Além disso na #267 eu tentei já adicionar a ideia da #257, que no caso dela ainda tem que ser feito de uma forma meio manual. Na #267 o jekyll cuida disso automaticamente durante o build. E cai no mesmo caso que essa, supondo que a #267 entre depois da #257, eu teria que desfazer tudo que foi feito nela pra minha entrar, porque elas implementam a mesma funcionalidade de formas bem diferentes. Eu alterei não só a estrutura de diretórios, mas também usei o jekyll pra fazer muito dessas coisas que foram feitas em js ou python nessas PRs. Inclusive na #267 resolvi a parte do sass também. Mas só adicionei todas essas mudanças de 1x porque já que a mudança vai ser "grande" (incluir o jekyll envolve outra ferramenta, mudar a estrutura de diretórios e tal), pensei em já fazer isso direito, e até pra mostrar que adicionar essa ferramenta tem ganhos em várias frentes. Resumindo, entendo o medo de adicionar complexidade, mas acho que o ganho vale. Por isso que eu sugeri tu dares uma olhada em como ficou o código e ver se faz sentido pro projeto. Eu posso se quiseres fazer a documentação e aí tu dás uma olhada. Só não fiz ainda porque eu queria uma certeza de que isso ia ser usado, fazer a documentação é sempre meio entediante haha. |
PS: talvez ver o diff da PR seja meio ruim, acho que é melhor ver a descrição da PR que eu explico a estrutura de pastas e ver o código do repositório em https://github.com/george-gca/diciotech/tree/jekyll2. Acho que fica mais fácil de entender as mudanças. |
Dá uma olhada também @azevgabriel vê o que tu achas. |
@azevgabriel eu finalmente consegui dar um bizu nas coisas por aqui 😆 Não sei se conseguiu dar uma olhada no PR do @george-gca, acho que vale seguirmos por esse caminho, vai facilitar futuras implementações e vamos focar em ter um documentação boa para manter o propósito do projeto que é ser um projeto Open Surce amigável para as pessoas contribuirem! Quero muito te agradecer pelo tempo e dedicação que você colocou nesse PR. Ele trouxe ideias e soluções muito valiosas, suas contribuições são sempre muito bem-vindas, e espero ver mais delas no futuro 💙 |
O que foi feito?
assets/data
cards_en.json
: Adicionado um JSON dos cards traduzidos emen
;tags.json
: Foi acionado um JSON que traduz as Tags;cards_pt-br.json
: Os textos das tags foram alteradas para as chaves do JSON de Tags. Isso é, sempre vão ser filtradas pelo mesmo texto, idependentemente do idioma.index.html
js/
translate.js --> getCards
: Foi adicionado na lógica, uma lógica de importação de cards por idioma;translate.js --> getTags
: Foi adicionado na lógica, uma lógica de importação de Tags por idioma;script.js --> insertTagsIntoSelect
: Foi alterado a lógica, onde a gente tem um valor diferente do texto e reset das options quando muda o idioma. value: sempre em inglês e text: sempre co a lingua traduzida;script.js --> getTagsFromCards
: Foi removido essa lógica.O que precisa ser feito?