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 slot into a template like this, and would likely also
have different images and stuff lke that.
On 11/3/05, hugo <[EMAIL PROTECTED]> wrote:
>
> >5. Similarly, I don't like the changes to the template code.
>
> Yeah, that part is the biggest problem with translations. The main
> problem here is: translation of sourcecode is easy. Translation of
> templates is hard. It's because templates are "turned around" with
> regard of code/text ratio. More text, less (hopefully) code.
>
> > <title>{{ _('Title') }}</title>
>
> Again, this is needed to mark the part that needs to be translated. If
> I don't mark that part, but just use HTML, I would need the string
> puller to know about HTML. But what if the user writes XHTML templates?
> Or when this is a YAML template? Or a simple CSV format?
>
> >And *I* barely understand what::
> >
> > <p>{% i18n ngettext('There is %(count)d file', 'There are %
> >(count)d files', files|count) %}</p>
>
> Yes, that one usually puts people off, if they first work with
> translations. The problem here: string translation is easy.
> Pluralization is a real bastard.
>
> The main reason why pluralazation needs this rather clumsy format with
> two _full_ translations (and not just part translations) is that
> languages handle pluralizations differently. Some languages have only
> two forms: plural and singular. But even those languages might behave
> differently with regard to the zero: what if there are _no_ objects?
> Is zero a singular, or is it a plural? Depends on your language.
>
> But then there are languages that have a different concept. I call it
> "troll counting" after the nice description by Terry Prattchet how
> trolls count: one, two, three, many. :-)
>
> There are many languages around that not only have a singular and
> plural, but have special forms for one element, two elements, more than
> two elements. So you need to provide the sentence and the count.
> gettext provides the singular and plural form because gettext takes the
> stand that the source language must be english (or at least a language
> whose pluralization is identical to the one of english). So you provide
> the sentence in singular and plural form and provide the count.
>
> The translators will provide the forms that are needed by their
> language and will provide a tag in the .po file that tells the system
> to do the different pluralization. And if you think that's a rather
> weird case, have a look at the "sr" language file in
> conf/locale/sr/LC_MESSAGES/django.po - it's using pluralization. It
> provides the "Plural-Forms" header for that purpose that defines the
> rules when to pull what plural form. I don't even know wether the
> python gettext library supports that fully, as it looks rather complex
> ...
>
> >is doing, and "leaking" %-style string formatting into the template
> >code seems ugly. Specifically, I'd like the template language to be
> >as losely coupled to Python as possible; I'd like implementations of
> >the template language on other platforms to be possible.
>
> We need to pull text flow and named parameters together. Another
> problem of translations is: languages order words differently. Ever
> heard an asian guy speak english in a funny yoda-style? It's because
> order of words and concepts is differently. It's even very different
> between english and german - and those languages are quite near to each
> other.
>
> So you need to put parameters in a named way into the translation
> strings. That's needed, so that translators can reorder the whole
> sentence. You can't just construct a translation out of translated
> parts - that's one of the biggest problems, you allways _must_ take
> semantic blocks and translate them in one go. So the only option is
> some kind of string interpolation to take place. Wether the syntax
> should be pythons string interpolation or some faked django template
> interpolation is irrelevant for execution. But it's relevant for
> editors, because there are editors that support the formats. That's why
> the .po files carry funny comments like "#, python-format" - that's a
> tag to tell the system how to handle those. Strings that have similar
> text, but different placeholders, will be handled automatically by some
> tools. The gettext tools themselves do that - they produce "fuzzy"
> translations, when there is a string that is - after removing all
> placeholders - similar to some other string. It will just pull the
> translation from that other string in those cases.
>
> So changing this format might break some nice effects for translators
> and maybe make their work harder - it would be a deviation from the
> gettext formats, and I am especially reluctant to do _that_ (yes,
> gettext has explicit and official support for python string
> interpolation syntax).
>
> > <title>{% translate "Title" %}</title>
>
> That's already possible by {% i18n _('Title') %} - the {{ _('Title') }}
> is just a shortcut for that, because it became a bit tedious to add all
> those i18n tag invocations :-)
>
> And since there are other tags that can have string constants, I
> thought it would be best to allow the i18n translated string syntax
> everywhere where we have strings. At least everywhere where it's easy
> to add, like with resolve_variable and resolve_variable_with_filters
> (the tag itself would still need to be aware of possible translated
> strings - that's a problem that stemms from the fact that django
> doesn't have a central tag-bit-parser).
>
> > <p>{% translate %}Hello, {{ name }}, welcome to {{ site }}!{%
> >endtranslate %}</p>
> > <p>{% translate %}There are {{ count }} {% pluralize count
> >"file" "files" %}{% endtranslate %}</p>
>
> I could do that - I already have a template-transformer that turns the
> templates into something grokkable by xgettext. But as I said, the main
> problem here would be the deviation form the gettext syntax. And it
> would be another problem: the part in between the translate block (or
> some i18n block in my case) would have to be first collected _without_
> rendering the interpolation elements - because we can only translate
> strings with placeholders.
>
> And what should happen if there are things in the blocktag like other
> block tags? Like this:
>
> {% translate %}
> This is a sentence {% if doit %}with something weird{% else %}without
> it{% endif %}
> {% endtranslate %}
>
> How should I handle this? I would have to pull _all_ text within a
> translate block tag and pull it together - uninterpreted! - as a string
> and store it in the .po files for translation. And what if that inner
> block tag is another translate tag?
>
> And what is a full non-option would be the pluralize thingy - in the
> light of different pluralizations it _can't_ possibly work. Actually I
> really dislike the pluralze tag ;-)
>
> We would still need something like:
>
> {% translate %}
> this is the singular case
> {% plural %}
> this is the plural case
> {% endtranslate %}
>
> But then there are still the problems about what to do with the inner
> block and possible block tags that are in there. The behaviour of the
> translate tag would be weirdly different from other tags: it wouldn't
> run it's inner nodelists through the template engine, but would first
> pull them together into a string, run that string through the
> translation engine and then reparses the resulting string and run
> _that_ through the template engine. Doesn't sound like an afternoon
> project ;-)
>
> >Thoughts?
>
> Yup. Loads of them. ;-)
>
> bye, Georg
>
>
--
[EMAIL PROTECTED] -- ++61-3-9877-0909
If everything seems under control, you're not going fast enough. -
Mario Andretti
