On 05.07.2013, at 13:57, Ned Batchelder <n...@nedbatchelder.com> wrote:
> On 7/4/2013 5:40 AM, Benjamin Wohlwend wrote:
>> Hi,
>>
>> I recently hit a problem where I have to provide translations for a reusable
>> app. In German (and most other languages, except English, it seems), there
>> are different second-person pronouns used in different situations, see [1].
>> As an example, the sentence "Do you want to log in" in its two German
>> translations: "Wollen Sie sich anmelden?" (formal, polite), and "Willst Du
>> dich anmelden?" (casual). Because my reusable app is used in all kinds of
>> projects, ranging from a social network to a banking website. Using "Sie" on
>> the social network is just as out-of-place as "Du" on the banking website.
>>
>> What I did so far is something like this:
>>
>> {% if is_formal %}
>> {% trans "Do you want to log in?" context 'formal' %}
>> {% else %}
>> {% trans "Do you want to log in?" context 'casual' %}
>> {% endif %}
>>
>
> Perhaps I'm naive, but would it work to treat these as two different
> languages? We already deal with Portuguese (Brazil) and Portuguese
> (Portugal), would it be possible for you to have German (Formal) and German
> (Informal)? Of course, part of that label would be provided by the user
> (German) and part by the app (Formal), but that composition and selection of
> language could be done in one place in the app, rather than everywhere
> strings appear.
For a end user project like Benjamin describes I can see that working -- but
only when using two separate PO files that both use the locale name "de". The
reason for that is simple: when Django tries to figure out which language to
activate (in LocaleMiddleware) it looks for the Accept-Language header in the
request. Since those headers follow standards (ISO 639-x) it won't have the
information about language specific variances, like formality. So making up a
name like 'de-formal' for example won't work in practice.
That said I'd prose the following work arounds, which is along the lines what
I've seen in other Open Source projects. The general idea is to have "language
pack". There are two ways to implement them (both outside of Django):
1. Two separate apps, e.g. 'formal_translation' and 'informal_translation'.
Each app has a 'locale/de' subdirectory with the appropriate translation. To
activate the translation you'd have to add one of them to the INSTALLED_APPS,
e.g.:
INSTALLED_APPS = (
# ...
'mysite.formal_translation',
)
Downside of that is that you'd have to write a small script to copy the po file
from the location the makemessages command saves to the app's locale directory.
One of the upsides would be the ability to distribute that translation
separately (~ "just run pip install mysite-formal-translation").
2. Use the LOCALE_PATHS settting.
That's very similar to the first option except that it does it all inside of
the project instead of a real app. Because it's a filesystem path this should
work best when you're maintaining both translations in the same repository and
don't want to distribute the translation as a separate package.
Note, there could easily be some things in makemessages that we could improve
to help those use cases, e.g. being able to specify the folder makemessages
writes the po files to. But I think this is an edge case where it might be
alright to ask the users to write their own management scripts instead.
Jannis
>> This gets very tiresome if you have more than a few translation strings.
>> It's not DRY, and it's error prone. As it happens, ticket #20383 would
>> provide the perfect solution for this, even if the use case therein is
>> different. I guess Claude was right in his assertion that the white labeling
>> use case might be to limited to warrant the additional complexity. The T-V
>> distinction problem, on the other hand, is present in (AFAIK) all Latin
>> languages, German, and many other languages. Is this enough reason to reopen
>> that ticket?
>>
>> Regards,
>> Benjamin
>>
>> [1]: https://en.wikipedia.org/wiki/T%E2%80%93V_distinction
>> [2]: https://code.djangoproject.com/ticket/20383
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
