email_address validasyonunda yerelleştirmeler eksik

sinansh commented 6 years ago

Email validasyonu için kullanılan gem'de gördüğüm kadarıyla i18n çalışması yok. Hata mesajlarını override edebiliyoruz. Override ederken hem TR hem EN yapabilir miyiz sorusuna cevap bulamadım şuan. Başka bir seçenek olarak gem'e katkı sağlayıp ilerleyebiliriz.

screen shot 2018-08-01 at 18 42 06

https://github.com/afair/email_address#override-error-messaegs

Bu soruna karşı nasıl bir yol izlemeliyiz?

roktas commented 6 years ago

https://github.com/afair/email_address/issues/24#issuecomment-390008047

sinansh commented 5 years ago

@msdundar hocam bu PR'ı kolay kolay @afair onaylamayacak gibi gözüküyor. Repoyu bizim organizasyona forklayıp Gemfile'a da bizim repoyu adres göstermek kısa vadede çözüm olabilir. Hem böylelikle bu iş kaydını da kapatmış oluruz. @afair reposunu güncellediği zaman tekrar orjinal adresine geçiş yaparız. Ne düşünüyorsunuz bu konuda ? @omu/backend

msdundar commented 5 years ago

İş kaydı açık kalsın, bir sakıncası yok. Şuan için geçici çözümlere sıcak bakmıyorum, bekleyip görelim.

sinansh commented 4 years ago

https://github.com/afair/email_address/pull/34

PR çok uzun süre merge edilmediği için kapatılmış, repoyu bizim organizasyona fork edip düzenlemeyi yapıp repo adresi olarak bizim repodan çekmeyi öneriyorum.

roktas commented 4 years ago

@sinansh Bunu yapmayalım, ekstra yük bizim için. https://github.com/omu/nokul/tree/email-address-workaround dalında bir çözüm ekledim. Rails'ın i18n alt yapısını doğru anlamışsam çalışması lazım. Sen veya @isubas bunu deneyebilir misiniz? Olay Validasyon'da bitiyor. Nokul'u bu dalda ayağa kaldırdıktan sonra geçersiz bir mail girin ve Türkçe ileti geliyor mu bakın. Eğer sorun varsa daha garantili ama bence buna göre daha çirkin bir çözüm var kafamda, onu uygularız.

roktas commented 4 years ago

Deneme yaparken uygulamanın 'tr' yerelinde çalıştığına emin olun. Test etmeden yazdım tüm kodu. Çalışmazsa panik yapmayın, hallederiz :-)

roktas commented 4 years ago

@msdundar böyle idare edeceğiz :-/

roktas commented 4 years ago

Son durum: önerdiğim düzenleme çalışmadı çünkü bu gem i18n özürlü. Kod genel olarak kötü ve bakımı da yeterince yapılmıyor. @ecylmz ile değerlendirme yaptıktan sonra https://github.com/micke/valid_email2 üzerinde karar kıldık. Emre'den gelen kod:

  validates :email, presence: true, uniqueness: true, length: { maximum: 255 },  'valid_email_2/email': {
    mx: true,
    disposable: true,
    disallow_subaddressing: true,
    message: I18n.t('users.account.activated')
  }

(alternatif olarak message: :invalid_email yapıp activemodel'e çeviri eklemek de mümkün)

Bu yolla gidildiğinde bazı testler patlıyor: https://github.com/omu/nokul/blob/develop/test/models/user_test.rb#L63 gibi. Bence strict RFC gitmemiz gerekmiyor, "usual" olmak daha doğru. Bu nedenle RFC edge case'leri kaldıralım derim.

P.S. Email'ı verify etmiyoruz, valide ediyoruz (email'lara ayrıca bir verified alanı eklenebilir). Burada genel bir ilkeyi işletiyoruz. Veritabanına kolayca çöp veri girilmemeli ve gerçek bir verify yapmadan yapabileceğimiz tüm denetimleri "çeşmenin başında" (yani sunucuda) yapmalıyız. Bu denetim "round-trip"leri önlemek için JS'le client tarafında da yapılabilir; ama ilkesel olarak backend'de daima yapılması taraftarıyım. Çöp verinin nereden ve ne şekilde geleceği belli olmuyor.

msdundar commented 4 years ago

JS tarafinda validate-js kullanilabilir. 0 harici bagimlilik, TS destegi, ECMAScript 5.1 (>=2011), epey zengin ozellik seti ve kucuk boyut (5kb):

omu / nokul

email_address validasyonunda yerelleştirmeler eksik #147