search

thismatters / django-mailinglist

Django package for administering outgoing mailing lists to subscribers.
GNU Affero General Public License v3.0
9 stars 1 forks source link

Internationalization -- German #6

Open thismatters opened 9 months ago

thismatters commented 9 months ago

Hi! I can't help but notice that you're working on translations for this project. Thanks for your interest!

I would be delighted to merge your changes if you're willing to have them merged. Is there something I can add to the repo to acknowledge your contribution? I was thinking of adding a CONTRIBUTORS.md to show some gratitude for anyone who takes the time to contribute.

gwaidacher commented 8 months ago

Hi!

I'm not done yet, I think it's missing a mechanism to store the set language code from request, when a user subscribes to a newsletter, eg through an additional column language_code (varchar 2 not null default = "en" - if there is no translation) in the Subscription model. This should then be used to set the corresponding language when sending the emails.

If you like to complete this issue, feel free to merge my branch!

Merry Christmas!

thismatters commented 8 months ago

Thanks for raising that issue. I'll see what I can do about managing the users' locale.

thismatters commented 8 months ago

I'm just thinking out loud here and I've never prepared a package for localization, so please contradict me if I've missed something. Any time the system is sending an email (a non Message email) to a user it is as a result of a request. We should be able to use whatever the users' browser says to use. I think that just having the gettext translations in place and having the project configured correctly should work. As far as Message email goes, there is no ability to send per-user translated messages in this package.

gwaidacher commented 8 months ago

I'm just thinking out loud here and I've never prepared a package for localization, so please contradict me if I've missed something. Any time the system is sending an email (a non Message email) to a user it is as a result of a request. We should be able to use whatever the users' browser says to use. I think that just having the gettext translations in place and having the project configured correctly should work.

Yes, that's the easy part. It could be tested with a language - switch in a base template which will appear automatically if there is more than one language configured in the settings: LANGUAGES = ( ("de", ("German")), ("en", ("English")), )

As far as Message email goes, there is no ability to send per-user translated messages in this package.

And this will be the difficult part; my motivation to work on this issue was to send localized Message content. I already altered the admin.MessagePartInline to inherit from TranslationStackedInline. Unfortunately I don't have much time to proceed with this issue at the moment; so if you merge my branch, this should then be reverted to inherit from admin.StackedInline again.

My next steps would be to take a look at the services, to find a way to switch to the desired language. Thinking about it, it should be better to store the language-preference within the Subscription, so a user will receive the Message in the language which is set at the moment he subscribes to a newsletter.

thismatters commented 8 months ago

Have you made accommodation for persisting the various translations of the Message content?

thismatters commented 8 months ago

I was thinking about your use case and it seems to me that it could be more easily handled by configuring localized mailinglists. If you created a separate mailinglist for each language you wish to support then the internal routing on the site could funnel users to the appropriate signup page. The backend effort to support this scheme is only slightly increased because you would have so publish and send messages for each separate list; but there would be no added work in composition and proofing (arguably the composition and proofing would be simpler with separate mailinglists per locale).

gwaidacher commented 8 months ago

I was thinking about your use case and it seems to me that it could be more easily handled by configuring localized mailinglists. If you created a separate mailinglist for each language you wish to support then the internal routing on the site could funnel users to the appropriate signup page. The backend effort to support this scheme is only slightly increased because you would have so publish and send messages for each separate list; but there would be no added work in composition and proofing (arguably the composition and proofing would be simpler with separate mailinglists per locale).

all right, this seems to be a promising approach

gwaidacher commented 7 months ago

Have you made accommodation for persisting the various translations of the Message content?

no, not yet.

gwaidacher commented 7 months ago

I just removed translation for admin.MessagePartInline