Hi,
>Currently I have setup where I have two (almost) separate project
>which use same set of templates, so I'll be needing some way to
>manually set path to locale directory because my templates are
>outside of the booth projects.
I added an optional LOCALE_PATHS setting that you can use in you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-10-2005, at 16:05, hugo wrote:
Generally, discussions about the i18n stuff should take place
somewhere
where I can see them, if it's expected to be something I should take
into account in the branch :-)
Well, this is more Serbian only or
Hi,
just some heads-up on the i18n stuff: I am now mostly done with the
first part of implementing the base code. So I switched my gallery site
- http://viele-bunte-bilder.de/ - to use my branch and to run it. So
you can see the first app running with full i18n.
The source to that gallery stuff
>to Petar: We can continue this discussion on DPT or ICQ.
Generally, discussions about the i18n stuff should take place somewhere
where I can see them, if it's expected to be something I should take
into account in the branch :-)
Best way for online discussion would be the #django IRC channel on
That's a leftover - it is just there because the template stuff won't
translate well with xgettext (the multitude of quotes just make
xgettext woozy in it's head), so they are translated to some other
format. The current make-messages.py changes the references back to the
original .html, now - so
On 10/11/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote:
> to Petar: We can continue this discussion on DPT or ICQ.
Agreed.
--
Петар Марић
Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'. - Michael McClary
On 11-10-2005, at 13:24, Nebojša Đorđević - nesh wrote:
Hey C8E, maybe I'm missed but I just found out that you registered
django on roseta (https://launchpad.net/products/django) :). When we
can use this to make django translation repository?
---
Nebojša Đorđević - nesh
Studio Quattro - N
On 11-10-2005, at 13:08, Petar Marić wrote:
Offtopic: I think it's for the best to recode the current translation
file to cyrillic, because we can use automated tools to make latin
translation out of that. Saves quite a some time.
If it's allright with you nesh, I would get right on it :)
Gre
On 10/11/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote:
> This is little off-topic.
>
> I'm looking to make both Serbian translations (latin and cyrillic).
> But, I'm failed to found any reference to _standard_ codes for that.
> Only idea I have is to make two codes - sr_LAT and sr_CYR and
On 10/11/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote:
> Is it's really necessary to change extension of html files to
> html.py? xgettext will be treat all files as python source because "-
> L Python" anyway. Petar Marić <[EMAIL PROTECTED]> told me that
> poedit have some issues with fil
On 11-10-2005, at 12:06, Nebojša Đorđević - nesh wrote:
This is little off-topic.
I'm looking to make both Serbian translations (latin and cyrillic).
But, I'm failed to found any reference to _standard_ codes for that.
Only idea I have is to make two codes - sr_LAT and sr_CYR and to map
s
On 5-10-2005, at 15:28, hugo wrote:
So I'd opt to leave that stuff out of the i18n branch for now and to
concentrate on the "translations for string constants" part and some
other branch or patch can introduce the "multilinguality of models"
patterns later.
Well, creating new field types are
On 11-10-2005, at 11:33, Nebojša Đorđević - nesh wrote:
from make_messages.py:
if file.endswith('.html'):
src = open(os.path.join(dirpath, file), "rb").read()
open(os.path.join(dirpath, '%s.py' % file),
"wb").write(templateize(src))
On 5-10-2005, at 15:28, hugo wrote:
From docs:
- $PROJECTPATH/apps//locale//LC_MESSAGES/django.(po|mo)
- $PROJECTPATH/locale//LC_MESSAGES/django.(po|mo)
- $PYTHONPATH/django/conf/locale//LC_MESSAGES/django.(po|mo)
Currently I have setup where I have two (almost) separate project
which use
Hi,
>I'm found while writing current application that this pattern is very
>common (almost a 2/3 of my models are using some type of localized
>name/description fields) and it will be great that i18n/model
>framework supports that without any additional code.
I agree that this is a rather common
Another helper function which I use often to get language dependent
objects from database. I think that's this case is common enough to
put support for that in the framework (see below).
code
from django.utils.translation import get_language
from django.core.exceptions import Obje
On 3-09-2005, at 12:11, hugo wrote:
I did change the LANGUAGE_CODE stuff for the DjangoContext a bit,
because LANGUAGE_CODE is only defined on the request if you have the
i18n middleware loaded - now the DjangoContext either carries
request.LANGUAGE_CODE or settings.LANGUAGE_CODE.
Oooops, I
> what about dropping the "django_" part of the name? something like
> "../?locale=de" seems neatier to me... or maybe i18n_locale, if
> polluting namespace bother you...
I chosen django_language (not django_locale - we are only switching
languages, not locales currently ;-) ) because it's unlike
ciao (djangonauts™ ;) )
2005/10/3, Nebojša Đorđević - nesh <[EMAIL PROTECTED]>:
> Also in get_language_from_request I added support to set language via
> GET parameter and store that selection in the session or cookie, so
> you can set current locale (and store it) with .../?django_locale=de.
wha
> Great, but I want to have globally accessible language code (i.e. to
> select news based on current language), so I added method to get
> language to your Translation object and a helper function
> get_language to get current language. Also I added LANGUAGE_CODE and
> LANGUAGES to DjangoContext
On 3-09-2005, at 11:29, Nebojša Đorđević - nesh wrote:
Also I added LANGUAGE_CODE and LANGUAGES to DjangoContext
I'm forget to say that LANGUAGES will be in model choices format, i.e.:
LANGUAGES = (('en', 'English'), ('sr', 'Srpski'))
so I can use it as a choices for my models.
---
Nebojša
Hi,
> your implementation for template tag don't have any plural
> support. You can probably add something like {% i18n ngettext(x,
> 'singular', 'plural') %}, patch is attached (untested).
Yep, plural support was missing up to now. I took your patch and
applied it and added some more stuff to s
On 30-09-2005, at 20:36, hugo wrote:
I did subclass the GNUTranslations, but actually if you want a db
store, it's easy to integrate later on. For now I think staying with
gettext and .po/.mo is the way to go - you can easily deliver .mo
files
with your django app to people that want to use yo
Hi!
>I'm just now see that you posted diffs in ticket #65 and created a
>branch.
Yep. I did it a bit differently than in youre patch: I tried to boil it
down to the smalles possible patch to have everything that is needed to
get i18n started, but not too much. I think it's much better to have
sm
> I'm currently finishing my first site with django and my i18n
> implementation (beta version of the site will be probably published
> this week), currently without translated admin interface (I don't
> have time to do that for now - deadline is closing :( ), but all
> other parts of the site are
On 12-09-2005, at 9:49, Lalo Martins wrote:
- We have a component called "translation service", which loads the
message catalogs and indexes them in memory.
My i18n implementation currently load translations when a
request is created (using LocaleMiddleware) and store translation
obje
I'm one of the people who put i18n into Plone (and incidentally, I also
worked on Rosetta). The company where I'm working now is switching to
Django. So you can count on me to help with this i18n thing :-)
So, the way we do it in Plone (since someone asked on the wiki), is
more or less like thi
On 11-08-2005, at 11:39, Nebojša Đorđević - nesh wrote:
set_translation(languages, app_name=None)
-
Sets *global* translation via get_translation()
current_translation()
-
Returns current *global* translation
*gettext functions
---
On 11-08-2005, at 11:39, Nebojša Đorđević - nesh wrote:
This is done calling setup_locale() from HttpRequest inside
*Request constructor because *Request classes don't call base class
(HttpRequest) constructor.
Update:
I just found-out that this is not correct way to do it :(
When I try to
I think it's a time to go for implementation of i18n, so first things
first. Let's define i18n interface and behavior:
This is RFC :)
When discussion is done, update http://code.djangoproject.com/wiki/
InterNationalization with information gathered from here.
Files:
==
* i18n module is
30 matches
Mail list logo
