Proposta de Internacionalização about tabnews.com.br

[tom-rb]

Fala pessoal, como tudo em engenharia de software, temos um belo compromisso a ser feito. Eu tendo a preferir um design mais cauteloso da fundação para prevenir grandes retrabalhos no futuro, como questionado pelo @danwhat, mas temos que avaliar direito o custo benefício. Trago um gráfico que ilustra essa ideia (da lenda Martin Fowler, https://martinfowler.com/bliki/DesignStaminaHypothesis.html):

Não tenho experiência com React, mas imagino o quão simples de usar deveria ser um sistema que permita localização. Vai incluir uma data no rodapé? Usa um <LocalizedDate date={createdAtUtc}></LocalizedDate> da vida. Vai mostrar um número? <LocalizedNumber value={coinsCount}></LocalizedNumber>. E por aí vai. Já a tradução de strings (fora das notícias em si, mas aí seria outra responsabilidade no sistema), eu imagino ser um pouco mais chatinha de manter e usar.

Com isso, ter um conjunto de componentes afinado assim, e todo o gerenciamento de rotas necessário (tipo tabnews.com/pt-br/), não é pouca coisa. É bem fácil que um esquema desses acabe atrasando mais as iterações iniciais e demore para se pagar. Acho mais provável que o "retrabalho" necessário para incluir essas features valha a pena se implementado um pouco mais pra frente (milestone 7?) do que nas etapas iniciais.

Dito isso, armazenar datas no banco de dados em formato UTC é uma boa prática que não deveríamos abrir mão. O custo inicial é baixo (converter de UTC para o locale do navegador é simples), previne diversos bugs em relação a fuso horário (só o Brasil tem 4!), e tomar essa decisão depois do sistema estar rodando exige uma migração de timestamps que é um problemão que pode ser evitado.

[danwhat]

Muito Bacana! Eu sou bem crú nesse assunto e não sabia dessa diferença.
A efetiva Internacionalização seria implementada bem mais pra frente, mas precisamos pensar nela a partir de agora para diminuirmos os custos da implementação no futuro.

Meu questionamento é: existe algum padrão ou check list de coisas que seriam legais serem implementadas agora para que la na frente não tenhamos que reconstruir tudo do zero?

[valdirmendesdev]

Galera, estou passando pelo processo de internacionalização/localização neste momento do produto que trabalho. Realmente é muito trabalhoso e arriscado depois que já existe uma estrutura funcionando.

Se houver alguma mínima chance de escalarmos globalmente o Tabnews (que acredito muito que será), acho que seria muito interessante já deixarmos a estrutura preparada, mesmo que inicialmente utilizemos apenas pt-BR. O retrabalho no futuro vai ser minimizado.

[francopan]

Fala Carlos, tudo bem! Obrigado pela sua contribuição!

Eu estava pensando a mesma coisa que você! A ideia do TabNews é muito boa e escalaria fácil. Tanto que se pegar tração, pode ser replicada no mundo inteiro. Isso trás, como sempre, riscos e oportunidades (os dois quase sempre são a mesma coisa).

• Oportunidades:
  • Ampliar base de usuários (maior renda?)
  • Mais Notícias e notícias cada vez mais relevantes
  • Networking com usuários de diferentes países e culturas
• Riscos:
  • Custo de servidores
  • Necessidade de criar workspaces para línguas diferentes ou usuários selecionarem o(s) idioma(s) que sabem usar.
  • Copycats do TabNews poderiam surgir em outros idiomas caso não sejam implementados ou o TabNews demore para implementar (concorrencia). - Sendo open-source já teriam um código completo de partida 😨
  • Left-to-right precisaria ser convertido para UI que aceite right-to-left (para idiomas árabes e asiáticos, por exemplo)
  • Lidar com diferentes timezones (salva-se tudo em UTC, mas precisa apresentar as informações no horário do usuário). Se uma newsletter matinal for criada futuramente, precisará considerar isso.

Considerando as milestones do projeto e os itens listados cima, diria que essa feature é necessária, mas poderia ser encarada como "cereja no bolo". Pois antes de atingirmos um público internacional, precisamos primeiro conquistar o público nacional.

[CarlosZiegler]

Ola pessoal, descupe o Delay, mas estava corrido aqui. Acho que pegaram muito bem o problema, acredito que o custo de "preparar o terreno" seria menor agora do que implementar isso em um futuro. Talvez nao precisariamos implementar mais idiomas de inicio mas deixar ele pronto e configurado para que em um futuro possa trabalhar sem ter que reescrever metade da aplicacao.

[filipemoraes]

O que o @filipedeschamps escreveu é uma excelente análise e não acredito que seja falta de visão, muito pelo contrário. Isso me faz lembrar os antigos marinheiros que em meio a tempestade retiravam do navio tudo o que não era essencial para manter o navio na superfície, e isso incluía a comida.

As ideias são boas mas precisamos manter o Tabnews na superfície e para isso precisamos ter em mente 2 coisas:

1. É um MVP.
2. Tal como qualquer MVP, precisa ser validado.

Um passo de cada vez

A internacionalização é algo importante mas na hora certa. Acredito que temos que tratar o Tabnews tal como ele é, ou seja, um MVP. Acredito que fazer bem feito a versão para o Brasil e validar o produto é o primeiro passo.

Não é apenas uma questão técnica

A internacionalização não é apenas uma questão técnica, existe toda uma logística para fazer com que o produto seja bem recebido por outras comunidades e isso consome muita energia que hoje acredito ser essencial para finalizar o MVP.
Não podemos simplesmente resolver o problema técnico e esperar que o fato de termos o produto em outro idioma seja suficiente para dar certo.

Primeiro precisamos fortalecer a nossa comunidade, ela precisa crescer e acreditar no Tabnews, sem ela não há motivos para continuar. Uma comunidade engajada é um pilar essencial do projeto e é nesse ponto que deveríamos gastar energia numa primeira fase.

Há espaço para evoluir

A internacionalização é o futuro provável mas que não precisamos necessariamente projetar já. O que estamos a construir não está imune a mudanças profundas no futuro, ao negar isso estamos fadados ao fracasso, mas isso não quer dizer que temos que pensar em tudo por causa de um provável cenário, é melhor fazer bem o que temos por agora. A nossa estrutura tem que servir muito bem ao nosso propósito atual.

Os nossos objetivos podem e devem mudar ao logo do tempo. Se chegarmos ao ponto de internacionalizar o Tabnews, isso significa que ultrapassamos muitas fases do projeto com sucesso e agora o nosso objetivo mudou e nossa estrutura mais uma vez deve ser adaptada a fim de atender ao novo propósito. Com uma base muito forte e consolidada, por mais trabalhoso que seja, será um passo dado no momento certo.

[wcarugatti]

Pessoal, por que estão afirmando que internacionalizar hoje trás custos maiores?

O principal custo que vem na minha cabeça seria tradução mas já que é open source meio que isso se anula.

Servidor e etc o custo por usuário acredito se manter o mesmo.

E pra fechar apesar de eu não fazer ideia ainda sobre como a plataforma vai se monetizar, o publico internacional "vale" mais por conta do dolar x real e etc.

Por conta desses motivos eu levanto a bola de se internacionalizar desde o inicio.

Num projeto de startup meu inclusive pretendo fazer o oposto, começar lá fora e só depois trazer pro Brasil, já que a aws custa igual e lá fora é mais rentável.

[filipedeschamps]

Eu acho a ideia do TabNews internacional simplesmente sensacional, sinceramente seria um sonho ter um ecossistema saudável na internet que pode ter a participação de pessoas inteligentes vindas de qualquer parte do mundo. Mas a natureza não vai deixar isso barato... nunca uma oportunidade realmente boa sai barato e os motivos sempre são inimagináveis 😂

É bem fácil que um esquema desses acabe atrasando mais as iterações iniciais e demore para se pagar. Acho mais provável que o "retrabalho" necessário para incluir essas features valha a pena se implementado um pouco mais pra frente (milestone 7?) do que nas etapas iniciais.

Então pegando o gancho do @tom-rb , o que essa issue propõe é a maior batalha que pessoas de tecnologia tem no início de um projeto 😂

Minha opinião sobre internacionalizar o TabNews (e pode ser falta de visão minha e estou super aberto a correção), é que não será fácil lançar um projeto internacional e não tem nada a ver com a questão técnica (nem se fizer agora ou depois tanto faz), tem a ver com penetração do produto no mercado. O principal ativo do TabNews não é a tecnologia, e nem como estamos usando ela para aplicar nossas ideias (TabCoins, Xp, etc...), o principal ativo é a participação das pessoas aqui no repositório, depois participando criando notícias, comentando coisas com valor concreto e participando do fluxo completo de contribuição. E a versão brasileira é a que está mais próxima dessa realidade, pelo fato das pessoas sensacionais que se reuniram ao redor do canal, se tornaram membros e estão aqui nesse repositório discutindo isso ❤️ não tem nada disso construído no ambiente internacional, e construir isso é um longo caminho, longo mesmo, e um mar vermelho.

Então como a gente está tratando de um benefício que pode ser coletado somente num futuro distante (novamente, posso estar com a visão limitada), não me parece que esse recurso irá ajudar a garantir o sucesso da versão brasileira. E se não conseguirmos o sucesso dessa versão, não vai ter valido implementar internacionalização, mas o contrário vale. Minha cabeça faz um xadrez maluco de combinações quando penso a respeito, mas segue aqui apenas os dois extremos:

1. Implementamos internacionalização, mas a versão brasileira não funcionou muito bem:

• Ela era que estava mais próxima de poder funcionar, problemático.
• Não valeu o custo de implementação de internacionalização (aumentou a complexidade, mesmo que levemente, mas não tiramos benefício).
• E apesar dessa versão não ter dado certo, não teve muito a ver com internacionalização, até porque o recurso foi implementado, mas não foi usado.
• Então isso não bloqueia o projeto de ser relançado em inglês.
• Mas como criar público internacional? Começando com um canal no YouTube em inglês?
• Só que novamente, se não funcionou no Brasil onde estava mais próximo de funcionar, porque funcionaria internacional?

2. Não implementamos internacionalização e a versão brasileira funcionou:

• Ótimo, se engatou e é economicamente viável, dá para pagar qualquer custo de outras implementações, principalmente porque o projeto não vai ser desenvolvido de forma chutada.
• De qualquer forma, com certeza vai ser mais caro implementar internacionalização.
• Mas antes, isso continua não garantindo nossa penetração no mercado internacional.
• Reunir público bom internacional ainda é um mistério.
• Como ter tempo para injetar energia nas múltiplas linguagens, principalmente em fomentar e moderar o público de cada uma?

Enfim, me gera uma sensação estranha nós colocarmos agora no presente um "imposto" ou "pedágio" a cada interação com o código (seja em alguém que está aprendendo a code base pela primeira vez, ou implementando algo novo), para estarmos melhores preparados para um benefício que pode ou não ser acessado num futuro, num tempo indeterminado (que eu especulei ser bem longo). Meu coração está me dizendo para primeiro garanta versão brasileira, que depois tudo vai valer a pena. E principalmente me sinto estranho em implementar algo agora sendo o principal motivo ter menos trabalho depois (Eu adoro a parte técnica, mas me preocupa isso ser discutido mais do que o critério "produto realmente sendo usado"). Mas, agora pela terceira vez 😂 , meu cérebro pode estar com pouca visão do futuro.

Qual a visão de vocês sobre esses pontos?

PS: diferente de internacionalização, mas com o mesmo princípio sobre "fazer agora ou" não, é o assunto acessibilidade, que tem um benefício real imediato e foi discutido na issue #43

[filipedeschamps]

Outro ponto que eu adicionaria é que (eu espero) que o core/interface do TabNews não seja algo extremamente complexo, ao menos quando comparado a um sistema legado de 15 anos, sem testes, e com partes que ninguém sabe como funciona. Quanto mais enxuto formos, mais fácil fica encaixar essas necessidades (e outras que a gente ainda não pensou, mas que vão se tornar necessárias).

[tcarreira]

Sugiro fazer uma limpeza das issues, e deixar abertas apenas aquelas que sejam úteis ter abertas.
Para issues deste tipo, que são ótimas ideias, mas que sabemos que não queremos seguir neste momento, sugiro criar um tópico na wiki, onde possa ser consultado mais tarde, mas que não esteja poluindo a lista de issues.

O que vocês acham?

[filipedeschamps]

A gente poderia mover discussões para aba de discussões (não lembro se esse recurso está disponível para todos os repos já) e deixar nas issues as tarefas mesmo.

E de qualquer forma, a gente poderia taggear essa issue aqui como repescar, para depois.

[danwhat]

Desculpe a demora na resposta.
O @tom-rb pegou bem minha preocupação. O custo que eu estava falando não era apenas financeiro, mas principalmente o retrabalho futuro. Acredito que exista algumas diretrizes que podemos seguir para que seja mais fácil a efetiva implementação lá na frente. Esse que foi o eu pedido da "check list". O próprio formato UTC é um exemplo simples de algo super simples de implementar agora, mas que vai economizar muita dor de cabeça no futuro.

---

Sobre o React, eu tenho experiencia e é lindimais usar ele; sou super a favor. Mas não sei o que o @filipedeschamps está planejando sobre isso.

[filipedeschamps]

Pessoal, adicionei a tag repescar e estou fechando ela até que seja o momento certo de voltarmos com o assunto 👍