On Nov 27, 11:10 am, Tim <[EMAIL PROTECTED]> wrote:
> For multilingual sites, is it not easier to maintain and keep all the
> translations in .po files? The idea of splitting up the required
> translations would mean that translators must use two different
> interfaces.

Well, those are two different sets of translators :)

It is the difference between code and content.  The .po files, just
like template files and all texts hardcoded in models and views and,
are 'code' and flatpages are usually the 'content' of your site.  The
latter are supposed to differ for separate installations of your app,
safer, changeable without modifications to the application code,
without risking breaking anything and thus editable by a larger group
of people.  This difference should be passed on to translations as
well.

I realize this line may be blurry in some cases, but a good way of
discovering where it goes is to think about using your app or project
as a base for two different sites.

As for the original question, there is at least one app that gives you
flatpages with translations, based on django.contrib.flatpages and
midified to use django-multilingual (http://code.google.com/p/django-
multilingual/issues/detail?id=30); I did not have the time to add it
to the multilingual library yet (unfortunately, this is where the "as
time permits" part kicks in), but hope to do so soon.  Should be
simple to install and try out and I would be happy to have some
feedback on what and how it does :)

-mk

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to