Hey Shai,
> I think improving the translation facilities is, indeed, a noble goal.
:)
> Reading this thread raised the following questions for me:
>
> 1) Do you intend to have more than one backend supported in one project?
>
> If not (as implied by your I18N_BACKEND setting), this means that tr
Hi Marinho,
I think improving the translation facilities is, indeed, a noble goal.
Reading this thread raised the following questions for me:
1) Do you intend to have more than one backend supported in one project?
If not (as implied by your I18N_BACKEND setting), this means that translations
Hey Jonas :)
> Let's assume for a moment we use your idea and provide a couple of different
> backends to store your translations. How would third party applications ship
> default translations then? At the moment they use gettext pofiles and it
> works like a charm. Let's assume now for my projec
Okay let's leave the database content problem besides here.
Let's assume for a moment we use your idea and provide a couple of different
backends to store your translations. How would third party applications ship
default translations then? At the moment they use gettext pofiles and it
works li
Hey Jonas, good afternoon :)
> Okay I would like to jump in here quickly and give my two cents on this
> topic.
great :)
> A very important distinction that should be made is the difference between
> 'dynamic' and 'static' translations.
> I call translations 'static' when they're strings that ar
Okay I would like to jump in here quickly and give my two cents on this
topic.
A very important distinction that should be made is the difference between
'dynamic' and 'static' translations.
I call translations 'static' when they're strings that are fix in the
templates (eg the text on the log
One more thing I forgot:
>> - In the database backend, how would plural forms of strings work in
>> languages with multiple plurals?
The database backend will not be the best in all features. In the same
way that "localmem://" it's not better than "memcached://" but
sometimes it's necessary, dat
Hey :)
>> Are you happy translating very long "django.po" without can just split
>> it in many files or just database records stored in cache?
>
> It gets the job done, yeah. For complex translations I've used Pootle and
> Transifex, both of which can import/export PO files.
yes, it's what we do
On 28.12.2010, at 18:33, Marinho Brandao wrote:
> Are you happy translating very long "django.po" without can just split
> it in many files or just database records stored in cache?
It gets the job done, yeah. For complex translations I've used Pootle and
Transifex, both of which can import/expo
Hey :)
> Well, I actually didn't mean forms and widgets with "translation of UI
> elements", but the "UI" of your website/project compared to the "data" that
> is displayed on it (e.g. from models). The first is covered by Django fairly
> well by using the industry standard gettext. The latter
>> The big issue I see here (at least from what I understand) is that content
>> translation and translation of UI elements
>> are completely different stories due to the way those content types differ
>> in structure and storage. Adding a
>> backend system implies having a common API, but I don'
Jannis,
I tried to be more clear with a long comment in the ticket [1].
Please, I wrote that from my mind without revise anything. It's just a
trial of make the idea more clear.
[1] http://code.djangoproject.com/ticket/14974#comment:4
On Tue, Dec 28, 2010 at 2:38 PM, Marinho Brandao wrote:
> H
Hey Jannis,
> Repeating what I said on the ticket, I don't quite understand what you mean
> by backend system.
A "backend system" is almost the same of design pattern "Adapter" [2]
that is used in many of functions of Django:
- Cache backends
- Emails backends
- Messages backends
- Authenticati
On 28.12.2010, at 12:32, Marinho Brandao wrote:
> But I'd like to suggest that we could make a backend system, like we
> have for many other components of the framework. So the developers
> could choose between gettext and database or create their own
> backends, with their dynamic sollutions.
Re
Hey people :)
I did open the ticket #14974 with a suggestion to make a backend
system for Internationalization component, in a contrib app.
Gettext is a good tool but limited to static files, and it sucks when
you work with long texts, you know: it gets a little unstable when the
message IDs are
15 matches
Mail list logo
