Re: Django i18n design rationale

[Raphael Michel]

Hi,

Am Fri, 1 Jan 2016 15:29:16 -0800 (PST)
schrieb Jure Erznožnik :
> 1. Expressions gathering vs declaring: Django has utilities to gather 
> expressions from sources, txt files and also javascript files. While
> that by itself is a design choice, it also presents us with problems
> such as (possibly very) long expression keys, random .po file layout,
> etc. Are there any serious advantages that favor this approach vs
> declarative one?
> 
> 2. What's the point of .po / .mo files? Their structure is not really
> far from standard Python code, so why all the work with compilation?

I wasn't around Django at that time, but to mee it seems pretty
clear that those two aren't explicit design decisions made by Django but
instead Django just decided to use gettext[1], the de-facto standard for
internationalization in the Unix world instead of implementing an own
system and both the gathering and the .mo files are old design
decisions of gettext.

Cheers
Raphael

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160102181247.169dd19e%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpRZpypRzTUK.pgp
Description: Digitale Signatur von OpenPGP

Best practice for two variants of a language

[Raphael Michel]

Hello,

I develop an open source web application in Django that is available in
multiple languages, translated using Django's gettext features. However,
in my native language German (and many others, too), there are strong
differences between formal and informal style (in German there is even
a formal and an informal word for "you").

Some of my users need to use formal language and others need to use
informal language and both have good reasons for that. So my question
is: Is there a best practice on how to implement this?

Contextual markers[1] are not an option, because you'd have to scatter
the decision all over the code base, so you need to have different
translation files for the different styles.

I could use different gettext domains, but this would be pretty
non-standard as Django normally uses only the "django" and "djangojs"
domains. 

I could also abuse language code by using "de-formal" and "de-informal"
instead of "de", but this would break Django's own translations (e.g.
of validation error messages).

Has anyone solved this problem in an elegant way before?

Cheers,
Raphael


[1]
https://docs.djangoproject.com/en/dev/topics/i18n/translation/#contextual-markers

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20150729115805.4e53c25f%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpmhqLqgtyZH.pgp
Description: Digitale Signatur von OpenPGP

Re: Django multiple application with common users

[Raphael Michel]

Hi,

Am Mon, 16 Mar 2015 01:23:22 -0700 (PDT)
schrieb Domagoj Kovač :
> I would like to have separate databases for every application
> including user management.

I can think of:

(a) You put all the application in the same database and share a user
model (look up 'reusable django apps')

(b) You let all applications have their own database but share one
common user database (look up 'django multiple databases')

(c) You set up the apps completely separated and use an external,
independent authentication provider (look up 'django ldap', 'django
openid', …)

For 'small home apps', I'd absolutely go for (a).

Best regards,
Raphael

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20150316114913.47790ae7%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgp1WzAsUUHuj.pgp
Description: Digitale Signatur von OpenPGP

Re: Django structure

[Raphael Michel]

Hi,

I'll leave it to others to give recommendations on how you SHOULD
organizer your project. However, I can help you with the technical
question.

Am Sun, 8 Mar 2015 11:53:09 -0700 (PDT)
schrieb Gabriel Klein :
> My question is how to shared models across apps? 

You can use models across apps without any problems, just as you would
inside the same app:

from otherapp.models import MyModel

Raphael

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20150308202624.6e3ae839%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpu4C2cwPdAy.pgp
Description: Digitale Signatur von OpenPGP