Re: Catalan translation
You're right. I looked into stable release, and at l10n page where catalan translation is missing. I just realized on it after writing my message. My mistake. Anyway, probably it'll be a good idea updating that page. :) Malcolm Tredinnick wrote: On Wed, 2007-06-27 at 16:47 +, the_kid wrote: Hi guys, I'll start catalan translation. If anybody has already started it, or want to contribute, please let me know. Perhaps you should look at the source code first. Marc Fargas has been maintaining a good Catalan translation for quite a while now. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@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-I18N?hl=en -~--~~~~--~~--~--~---
Re: Language names Upper/Lowercase
In my opinion the main problem here, is that the original words appear
in global_settings.py with a dummy translation, so there's no place in
Django itself where those strings are used.
What I would do is translating the strings in lowercase when it's the
correct form for the language, without duplicating or anything like
that, and then the user will have to capitalize it if creating a drop
down list (what isn't a problem or something strange from my point of
view). For other uses of the language names, it will appear in lower
case by default, what it'll be probably the expected behavior for most
users, and them will be able to capitalize it when necessary.
PS: I'm not sure if a drop down list with languages should use any
translation, imagine that I've to select english from a language list
with chinese names...
On Jun 16, 11:44 am, mrts <[EMAIL PROTECTED]> wrote:
> All languages in my neighbourhood use lowercase language names:
> Estonian, Swedish, Finnish, Latvian, Lithuanian, Russian.
>
> Using separate msgids for lower- and uppercase looks attractive, but
> then the ids in source don't match natural English any more (e.g.
> explicit lowercase could be used in the ids where they don't start a
> sentence: _("estonian")). That is a problem in case i18n is not used
> at all.
>
> _("Estonian") would be translated to en as "Estonian" and to et as
> "Eesti", whereas _("estonian") would be translated to en still as
> "Estonian" but to et as "eesti".
>
> Currently, Finnish django.po uses lowercase for language names, but
> Russian and Latvian django.pos use uppercase (which look unnatural and
> incorrect for native speakers).
>
> On Jun 16, 11:49 am, Marc Fargas <[EMAIL PROTECTED]> wrote:
>
> > Hi all,
>
> > Due to ticket #7461 an issue was raised about uppercase language names.
> > In English, languages are written with the first letter being uppercase
> > while other languages like 'es' and 'ca' write them lowercased unless
> > they're the begining of a sentence or single words.
>
> > This is currently impossible to distinguish with the current msgid's. So
> > two questions for everybody:
>
> > * Which languages are affected by the same thing? (That is, which
> > languages type language names lowercase unless beggining sentences or
> > single words).
>
> > * Any idea on how to get that information from the msgid's?
>
> > For the idea, one option would be having both msgid's (lower and
> > uppercase) so translation would be easy, but that would need the 'en'
> > locale to be up-to-date and having both msgstr set to uppercase. But
> > it's one possible solution. Ideas?
>
> > Thanks,
> > Marc
> > --http://www.marcfargas.com--will be finished some day.
>
> > signature.asc
> > 1KDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django I18N" group.
To post to this group, send email to Django-I18N@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-I18N?hl=en
-~--~~~~--~~--~--~---
i18n
Hi! I just wanted to point you out, that I started a thread on django- developers [1] about some improvements that could be done for a better i18n of Django. I'll try to include those changes on 1.0. [1] http://groups.google.com/group/django-developers/browse_thread/thread/db149543262b5b21# --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@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-I18N?hl=en -~--~~~~--~~--~--~---
Trying to standardize django field translation
As most of you should know, there exist some different projects for translating content in database when using Django. Every project has some goals, and some handicaps, but most of them are trying to fix the same problem. So in this specific case, some people (including myself) would like to see a project for translating fields that has the best of every existing project. With this in mind, I wrote a post on my blog [1], to let people vote which model syntax would like for this new project. This syntax shouldn't be related to any internal decision we'll take afterwards, so I think that you can vote even if you are just potential users of the future application. Also, if you want to join us on the development, design... just let me know. Thanks and regards, Marc [1] http://vaig.be/2009/03/django-multilingual-syntax-poll.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@googlegroups.com To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Django-I18N?hl=en -~--~~~~--~~--~--~---
About #7050 and not including on the catalog strings from applications already translated
Hi folks, I'm going to work on ticket #7050 [1], and there are different options that need to be discussed. Let me summarize what ticket tries to fix, and what needs to be decided... Imagine that we have a Django project including three applications, A, B and C. This project needs to be available in 3 languages (English as main language and Catalan and German). Also imagine that we got applications A and B from the Internet, and that the author already translated them to some languages. A is translated in both Catalan and German, and B just in German (the whole project including all applications is coded in English). App A (English, Catalan, German) App B (English, German) App C (English) So what happens when we execute "python manage.py makemessages -a"? Right now, what happens is that all strings from applications A, B and C are included on the project catalog. Of course that's not optimal, so we'll have to translate many strings that are already translated. So, in the case of the A application, probably the best would be just ignore it when creating the catalog. In the case of the C application, probably we should include its strings on catalogs for all languages. But the most controversial part is what to do with B. Should we include the strings from B in the Catalan catalog but not in the German one? This i quite of messy. But if we don't do that, then it should be translated inside the application, and that could be a problem in some cases (may be the application is a external on our subversion so we can't modify it). More complicated would be if one application is partially translated to a language. What to do in that case? Consider that the application is translated? Consider that it's not? Add to our project catalog just the strings that are not translated? IMHO I would prefer to keep it simple, and just ignore applications having a locale directory. Of course it'll be more work for developers who will have to create catalogs for missing languages in localized applications. And of course it'll be a problem if you don't have write permissions on the application. But I think that is better for (project) developers spending few time on creating some catalogs, than on figure out how things work (or why things don't work as they expect). One thing I'm considering, is if it would it be worth creating a parameter for the makemessages command (like --no-ignore) to force the inclusion of all strings on the project catalog. Thanks for sharing your opinion you too. Regards, Marc [1] http://code.djangoproject.com/ticket/7050 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@googlegroups.com To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Django-I18N?hl=en -~--~~~~--~~--~--~---
i18n gsoc
Hi folks, just wanted to let you know, that I started coding for the i18n refactorization, and that you can already check the changes at [1]. See details of what this changeset does at [2]. For now, checking that code is only worth for developers interested on Django itself, so actually nothing changed for the developer of Django applications. Hopefully you'll be able to check some new features soon. Regards and thanks for your feedback, Marc [1] http://code.djangoproject.com/changeset/10956 [2] http://groups.google.com/group/django-developers/browse_thread/thread/ef7415b32179122e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@googlegroups.com To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Django-I18N?hl=en -~--~~~~--~~--~--~---
i18n branch ready for testing
Hi folks, for those who don't know it, I've been working on a branch, where I fixed some bugs, and where I tried to improve Django's i18n in general. Basically what's done, is making Django consider current locale when working with dates, numbers and calendars. For example, admin's calendar, now, will start weeks depending on the current locale, not always on Sunday. Right now, this branch is in a kind of beta status, and feedback from the community will be great. To give it a try, follow next steps: * Get the branch from subversion [1], and use it for an existing project, or for a new one. * Set up you settings file, to make sure you enable all the formatting stuff. To do this make sure USE_I18N is set to True, and create a new setting USE_FORMAT_I18N, also set to True. * Check if all formats for your locales are set on the branch. We imported some of the formats from the CLDR (a unicode set of locale definitions), but there are some that are not available. Formats are defined in django/conf/locale//formats.py . You should check that there is no setting commented or lacking value, and if there is, please complete the file and mail me the patch, so I can include it in Django. You will find documentation on what every setting means on the settings documentation [2]. There is a list of tickets that have been fixed on this branch for now [3]. It could be a start on things to try. You can also check "Format localization" chapter on i18n docs [4]. Thank you for your feedback, Marc [1] svn co http://code.djangoproject.com/svn/django/branches/soc2009/i18n-improvements [2] http://code.djangoproject.com/browser/django/branches/soc2009/i18n-improvements/docs/ref/settings.txt [3] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&keywords=~i18n-fixed&order=priority [4] http://code.djangoproject.com/browser/django/branches/soc2009/i18n-improvements/docs/topics/i18n.txt#L1085 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@googlegroups.com To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Django-I18N?hl=en -~--~~~~--~~--~--~---
Django formats
Hi! I'm contacting you because according to Django localization page [1] you're a Django translator. The reason for this mail, is because I'm on the late steps of a new set of features of Django, that will allow applications to display data in locale specific formats (comma as decimal separator, Monday as first day of week, d/m/y dates...). To complete this set of changes, I need that Django translators specify some of the formats for their locales, in order to use them. I imported as much as I could from the Common Locale Data Repository, but there are some settings that are not there. Here you have the procedure, on how to do it: * Get the i18n branch [2] * Find you locale file in django/conf/locale//formats.py * Check English formats file [3] as reference, and also settings documentation [4] * Complete you locale file * Attach the patch to ticket #11637 [5] Thanks a lot, Marc [1] http://code.djangoproject.com/wiki/Localization [2] svn co http://code.djangoproject.com/svn/django/branches/soc2009/i18n-improvements [3] http://code.djangoproject.com/browser/django/branches/soc2009/i18n-improvements/django/conf/locale/en/formats.py [4] http://code.djangoproject.com/browser/django/branches/soc2009/i18n-improvements/docs/ref/settings.txt [5] http://code.djangoproject.com/ticket/11637 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@googlegroups.com To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Django-I18N?hl=en -~--~~~~--~~--~--~---
Re: Django formats
It surely won't be merged into trunk before August 17th (when GSoC ends), and probably it'll take more time than that. Anyway, formats will work more or less as translations, so if we don't have the ones for one locale, it'll use Django's defaults, so not having one shouldn't block the merge, and formats for that locale could be added later. Thank you, and let me know when having them, Marc Orestis Markou wrote: > Is there a timeframe for this? I can supply Greek locale data but not > in the next week. > > Thanks for your efforts! > > Orestis > -- > ores...@orestis.gr > http://orestis.gr/ > > > > > On 5 Aug 2009, at 15:06, Marc Garcia wrote: > >> Hi! >> >> I'm contacting you because according to Django localization page [1] >> you're a Django translator. >> >> The reason for this mail, is because I'm on the late steps of a new >> set of features of Django, that will allow applications to display >> data in locale specific formats (comma as decimal separator, Monday >> as first day of week, d/m/y dates...). >> >> To complete this set of changes, I need that Django translators >> specify some of the formats for their locales, in order to use them. >> I imported as much as I could from the Common Locale Data Repository, >> but there are some settings that are not there. >> >> Here you have the procedure, on how to do it: >> * Get the i18n branch [2] >> * Find you locale file in django/conf/locale//formats.py >> * Check English formats file [3] as reference, and also settings >> documentation [4] >> * Complete you locale file >> * Attach the patch to ticket #11637 [5] >> >> Thanks a lot, >> Marc >> >> [1] http://code.djangoproject.com/wiki/Localization >> [2] svn co >> http://code.djangoproject.com/svn/django/branches/soc2009/i18n-improvements >> >> [3] >> http://code.djangoproject.com/browser/django/branches/soc2009/i18n-improvements/django/conf/locale/en/formats.py >> >> >> [4] >> http://code.djangoproject.com/browser/django/branches/soc2009/i18n-improvements/docs/ref/settings.txt >> >> >> [5] http://code.djangoproject.com/ticket/11637 >> > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@googlegroups.com To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Django-I18N?hl=en -~--~~~~--~~--~--~---
Re: Django formats
Yes, sorry for not specifying. Just note that input formats use another syntax (the one used by datetime's strptime). On Aug 5, 8:15 pm, Finn Gruwier Larsen wrote: > I suppose this must be the relevant list of allowed format codes and > their mening: > > http://docs.djangoproject.com/en/dev/ref/templates/builtins/#ttag-now > > Regards, > > Finn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@googlegroups.com To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Django-I18N?hl=en -~--~~~~--~~--~--~---
Re: Django formats
Hi Rudolph, take a look at the English locale tests [1]. You could use it as reference for writing tests for you locale. I don't think it's worth to include tests for every locale into django, but if you do think so, just share them with me. Cheers, Marc [1] http://code.djangoproject.com/browser/django/branches/soc2009/i18n-improvements/tests/regressiontests/i18n/tests.py#L228 On Aug 8, 10:20 pm, Rudolph wrote: > Hi, > > Would it be appropriate to add (unit)tests for the formats? This > encourages all translators to actually test their formats before > submitting and of course it has all other benefits of testing. If this > is an good idea, I suggest to come up with an example set of tests so > that everyone can adjust them to their local needs. > > Rudolph Froger > > On Aug 8, 5:06 am, Marc Garcia wrote: > > > Yes, sorry for not specifying. Just note that input formats use > > another syntax (the one used by datetime's strptime). > > > On Aug 5, 8:15 pm, Finn Gruwier Larsen wrote: > > > > I suppose this must be the relevant list of allowed format codes and > > > their mening: > > > >http://docs.djangoproject.com/en/dev/ref/templates/builtins/#ttag-now > > > > Regards, > > > > Finn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@googlegroups.com To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Django-I18N?hl=en -~--~~~~--~~--~--~---
About multilingual models
Hi folks,
finally I had no time to start coding on multilingual models, as part of
my GSoC project. I did some more analysis on the problem, and possible
solutions; let me share them with you.
Basically, I arrived to the conclusion that there are two different
approaches, both valid, and everyone more suitable depending on the
website. Let me name these methods "model based" and "gettext like".
Summarizing, the model based idea is two define in every model the
structure for translating necessary fields. The gettext like method
would implement a catalog, and the translations would be decoupled from
the models.
Let's explain both methods in more detail:
model based method
-
This method is specially interesting in websites where all translations
are provided at the same time. The idea is that doesn't exist a main
language, and we don't want to show another language if the string
doesn't have a value for current language. Imagine you have a virtual
shop build in Django, and you sell products to the US and China. I don't
think it's useful displaying Chinese texts to Americans, or English
texts to Chinese users. Person inputting data on Django probably will
have product name and description in both languages in paper, Excel...
or any other media, so it makes more sense filling all data (in all
languages) at the same time, than entering the product in English, and
then translate in another place.
In this case the admin should allow filling all translations at the same
time, and if a field is required, it should be required for all languages.
In this case I would specify this syntax to let Django know that we want
this field translated:
class MyModel(models.Model):
my_i18n_field = models.CharField(max_length=32, translate=True)
Main advantage of this method is that we have the translate property
together with the field definition. This makes easy to know if a field
will be translated or not after coding the models.
From the database point of view I would create an extra table for every
model, with next structure:
* id
* main_table_id
* language_code
* field1
* field2
* ...
So, to get data would be necessary to join both tables filtering by
current language code. That would make easy to filter, sort or search by
any of the translated fields.
gettext like method
---
This method would be more suitable for websites where we provide a
content in one language, and then, we want to offer this content in as
much languages as possible. Imagine a kind of wiki. We write articles in
English, and then we allow users, or we hire translators, to make this
articles available in other languages.
In this case we pretty much emulate the way gettext works. We provide
the content in the main language (on the admin for example), and then
translators access those contents to provide translators. In some cases
it won't be strictly like in gettext, where you usually don't care much
what the text is used for. It would be great having the ability to
provide a link on every article saying "translate it to your language"
if it's not.
While the other method would also work for marking fields as able to be
translated, in this case I would choose something more decoupled from
models. I would use a syntax more close to the admin one. Just
specifying outside the models, which ones we want to translate, and
which fields. Main advantage of this syntax is that we can translate
fields from existing applications without modifying them.
class MyModelTranslation(multilingual.Translation):
translate = ('my_i18n_field',)
multilingual.register(MyModel, MyModelTranslation)
A database structure to support this functionality could be just having
a table named "catalog" where all translations are set. It would be like
a .po file:
* language_code
* msgid
* msgstr
also it would be interesting to provide information about the places
where this string is located:
* msgid
* model/field/id
There are two important problems with this structure. First one is that
filter, sort by translatable fields will be almost impossible. Searching
would be possible (but slow). Second problem is that we would have to
store all values as strings, or just allow translating strings, because
same field would be used to store all translations on the system.
Main advantage of this method is that is quite easy to decouple the
whole translation engine from Django. Modifying an existing application
to allow translating database content could be set up in minutes,
without modifying the existing code.
These are my thoughts about that. Both ideas still need more discussion
and improvements.
Regards,
Marc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django I18N" group.
To post to this group, send email to django-i18n@googl
Transifex
Hi there, as a language coordinator, I would like to see what other contributors translated in Transifex. Is it a way to do it? I can't find it. Another thing. I would like to know (if possible) how it'll be the procedure to update the code from transifex translations, and how code changes will arrive to transifex. I don't care on the details, but just to know if it's automated, how often it'll be done (or in other words, how long it'll take to a change in code/transifex to be updated in the other part). And most important, do we coordinators need to do anything? Thank you! Marc -- You received this message because you are subscribed to the Google Groups "Django internationalization and localization" group. To post to this group, send email to django-i18n@googlegroups.com. To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-i18n?hl=en.
Re: Transifex
Thanks for the explanations Jannis, and sorry for making you repeat the second part, I checked if you already explained this in this same list, but couldn't find it. Cheers, Marc On Feb 7, 1:12 am, Jannis Leidel wrote: > On 06.02.2011, at 23:48, Marc Garcia wrote: > > > as a language coordinator, I would like to see what other contributors > > translated in Transifex. Is it a way to do it? I can't find it. > > Not afaik through the web UI, although the Transifex developers could give > more details on that. I know an action log is saved, but I'm not sure if it's > possible to show it at the moment. FWIW, you can see the changes by looking > at the diff using transifex-client. > > > Another thing. I would like to know (if possible) how it'll be the > > procedure to update the code from transifex translations, and how code > > changes will arrive to transifex. I don't care on the details, but > > just to know if it's automated, how often it'll be done (or in other > > words, how long it'll take to a change in code/transifex to be updated > > in the other part). And most important, do we coordinators need to do > > anything? > > I've answered some of this in my initial announcemnt email: > > http://groups.google.com/group/django-i18n/browse_thread/thread/6bf6b... > > But to summarize: > > 1. The files in en/LC_MESSAGES/ in SVN will be updated on the day of the > string freeze at the latest, when the release candidate is released. > Aditionally, Transifex is set up to automatically sync them every day. > > 2. Translation updates made on Transifex are pulled into the Django SVN repo > prior to cutting a new release or whenever it's convenient. > > For both steps no intervention is needed from the language coordinators. > > Using transifex-client > -- > > Since it was asked before and I'm not sure if I've said it explicitly, > translators can also use the transifex-client [1] tool to push (assuming > permissions) and pull translations. It's the same tool that's used by the > core devs to pull updates from Transifex. > > For example, assuming you're in a recent SVN working copy, running this > updates the PO files of the German core translation: > > tx pull -r django.core -l de > > Next, after updating the German translation, you can push it up again: > > tx push -r django.core -l de --translations > > Jannis > > 1:http://pypi.python.org/pypi/transifex-client/ -- You received this message because you are subscribed to the Google Groups "Django internationalization and localization" group. To post to this group, send email to django-i18n@googlegroups.com. To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-i18n?hl=en.
