hugo wrote:
>>I'd love to see a use case for different styles and javascript according
>>to language. Of course it could already be done with :
>
>
> Easy: I have AJAX stuff that doesn't pull HTML from the server and just
> uses innerHTML, but just pulls JSON encoded flags and builds the whole
>
Eugene Lazutkin wrote:
> Just a thought.
>
> Isn't it possible to implement layout (structure) and text in separate
> templates? One template defines layout and blocks, another one extends the
> former and populates blocks with translated text and/or proper i18n tags.
> The idea is to have sev
>I'd love to see a use case for different styles and javascript according
> to language. Of course it could already be done with :
Easy: I have AJAX stuff that doesn't pull HTML from the server and just
uses innerHTML, but just pulls JSON encoded flags and builds the whole
HTML clientside. That j
Adrian Holovaty wrote:
>
> Agreed WHOLEHEARTEDLY! We've avoided Python syntax in template tags
> thus far, and this proposal goes completely against that.
>
> I must say I like Ian's proposal that the template_loader could load a
> different template based on language. That would avoid this whol
Just a thought.
Isn't it possible to implement layout (structure) and text in separate
templates? One template defines layout and blocks, another one extends the
former and populates blocks with translated text and/or proper i18n tags.
The idea is to have several "translation" templates, which
>In Russian it's slightly different. There are (generally) 3 variants:
>1. ending with 1 (except 11)
>2. ending with 2,3,4 (except 12,13,14)
>3. 11,12,13,14
That can actually be done with gettext, you have the C "%" operator
available and can do exactly those checks. What you do, you write C
expr
Maniac wrote:
>
> Robert Wittams wrote:
>
>> It would of course be another option. But not a particularly good one.
>> It means that when you change the template, someone has to merge the
>> changes into all the other languages. You will almost certainly end up
>> with your logic out of sync in
Nebojša Đorđević - nesh wrote:
3 IIRC, same as Serbian.
There are 3 declensions but actually different forms of declension are
more (including nouns, adjectives etc).
Three forms, special cases for numbers ending in 1 and 2, 3, 4,
except those ending in 1[1-4]
In Russian it's slightly
>Taking the example of pluralizations of quantities it won't work for
>Russian. Words depending on their form have different alforithms of
>adjustment for numbers. Typical words have 3-4 different forms for
>different numbers. And I can't tell exactly how many of those forms
>exist but it's like s
I think you need to do both.
we can worry about the template stuff after your i18n stuff gets
merged in I think.
it solves 80% of the issues for most languages.
--I
On 11/3/05, hugo <[EMAIL PROTECTED]> wrote:
>
> >I must say I like Ian's proposal that the template_loader could load a
> >different
>I must say I like Ian's proposal that the template_loader could load a
>different template based on language. That would avoid this whole
>problem, and it'd allow for more language-specific flexibility -- e.g.
Ugh. No. Templates are structure of pages - and the structure should be
the same over
On 2-11-2005, at 21:58, Maniac wrote:
Taking the example of pluralizations of quantities it won't work
for Russian. Words depending on their form have different
alforithms of adjustment for numbers. Typical words have 3-4
different forms for different numbers. And I can't tell exactly how
Robert Wittams wrote:
It would of course be another option. But not a particularly good one.
It means that when you change the template, someone has to merge the
changes into all the other languages. You will almost certainly end up
with your logic out of sync in different templates.
Nightmare.
On 2-11-2005, at 19:24, hugo wrote:
Actually I don't know any backward-incompatible changes, at least none
I am aware of. I think it should be possible to just run your project
after switching to the i18n branch without any _required_ changes.
When i18n branch is created I switched without an
I haven't had a chance to explore the i18n branch yet, but I plan to
spend some quality time with it tonight. Preliminary thoughts, based
on the current discussion, are below --
On 11/2/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> 3. I don't like that the translation context can be specifie
Ian Holsman wrote:
> Just a comment on the templates.
>
> wouldn't it be easier/another option for the template loader to just
> load a different template based on language?
>
> When i was investigating i18n issues for a similar project (a long
> time ago) that is what we came up with, as asian
Just a comment on the templates.
wouldn't it be easier/another option for the template loader to just
load a different template based on language?
When i was investigating i18n issues for a similar project (a long
time ago) that is what we came up with, as asian was just too damn
hard to try and
Hi,
>I wouldn't say that this totally disqualifies it. If there is really a
>big use case for people translating without installing django (which I
>find kind of unlikely), a translation bundle can be created with the
>extracted po files.
That's what I already do - provide ready extracted .po fi
hugo wrote:
> If people want translated modules, they need to provide translation
> hooks. The only way out would be to do model introspection additionally
> to the xgettext run - but that's problematic, too. Because you can
> only introspect models that are loaded. But if I for example want to
>
Hi,
>2. Once this hits the trunk we'll need documentation about any
>backwards incompatibilities this introduces and what the upgrade path
>looks like (in the style of the docs on the
>BackwardsIncompatibleChanges page). The translation document is great
Actually I don't know any backward-incom
Awesome ideas!
I agree with Robert with the plural form of translations.
+1
--
JP
Em Qua, 2005-11-02 às 17:08 +, Robert Wittams escreveu:
> Totally agree on the first 4.
>
> > 5. Similarly, I don't like the changes to the template code.
> > Basically, I don't want to have to explain i18
Totally agree on the first 4.
> 5. Similarly, I don't like the changes to the template code.
> Basically, I don't want to have to explain i18n to template authors
> (they shouldn't have to know anything about it) and explaining why
> someone needs to do::
>
> {{ _('Title') }}
>
> instea
Howdy folks --
I've had a chance to review the i18n branch, and here are my thoughts:
1. Awesome. Seriously, this rocks; all of my criticisms to follow
are trivial next to how cool this is.
2. Once this hits the trunk we'll need documentation about any
backwards incompatibilities this in
Hi,
>As a corollary of 4, I might try making an app for selenium ( in browser
>web testing thing from Jason Huggins & co). This would allow us to run
>regression tests against the admin ( and by extension, the manipulators
>etc.)
Like the python-zope-binding for Selenium? So that one can just in
Hi,
>Great read ;-) Any plans on how to adapt this as an add on for Django?
>(Seaside like?) The difficulty is that they are one-shot(no back
>button), and also you need some session affinity thing going on with
>your processes as greenlets aren't pickleable... oh, for stackless/pypy!
>;-)
Actua
hugo wrote:
> Hi,
>
>
>>Sounds good to me. The new-admin branch probably still does have a few
>>issues ( hard to test everything with this many changes!). There are
>>also just a couple of API issues (extra methods to be exposed on the
>>manipulator).
>
>
> I plan to use your new_admin branch
>here's the .po file.
In SVN now.
bye, Georg
Hi!
>Here is the patch for czech translation.
Please send translation files as full .po files - they aren't that big.
Applying patches sometimes produces problems (like with your patch -
don't know why exactly, but it just runs wild when applying) and it's
allways easier to just copy the transla
Hi,
>Sounds good to me. The new-admin branch probably still does have a few
>issues ( hard to test everything with this many changes!). There are
>also just a couple of API issues (extra methods to be exposed on the
>manipulator).
I plan to use your new_admin branch for my CMS thingy as soon as
hugo wrote:
> Hi,
>
> I think the i18n branch is ready for merging into trunk. I am using it
> on two apps (my gallery and my cms project) and it looks quite good to
> me. I first thought about adding some more translation hooks to the
> admin before merge, but I think that should wait: rjwittams
>I'll get back to the list today or tomorrow with any comments I have
>on the i18n branch; thanks again!
Ok, then I will refrain from any functional chanages to the branch and
only do translation updates, so that you have something functionally
stable to check and not a "moving target" to hunt ar
hugo --
I like your plan of attack, and svn switching to the i18n branch
didn't cause any headaches for me, so likely we're good to go. I'd
like to take some time to review the branch and see if there's
anything we should discuss, but at first glance I'm blown away by how
awesome this i
Hi,
>There are other parts that the i18n branch deliberately doesn't
>address, like date formats and other l10n stuff.
at least for date formats I added a sample on how it can be done. The
idea is to define technical message IDs for formats and to add the
language-specific date formats as transl
33 matches
Mail list logo
