I think that the best solution would be the one that is used for the template system. Specify load paths for project-wide catalogs, and default to application catalogs (not copy them to the common project catalog, just use them as they are).
On Tue, May 12, 2009 at 2:50 AM, Marc Garcia <garcia.m...@gmail.com> wrote: > > 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 > > > > > > > > > > -- Branko -------------------------------------------------- To leave a quick note to Branko, use this page: http://www.wallwisher.com/wall/foxbunny -------------------------------------------------- eml: bg.bra...@gmail.com alt: fox2bu...@yahoo.co.uk blg1: http://sudologic.blogspot.com/ blg2: http://foxbunny.blogspot.com/ blg3: http://brankovukelic.blogspot.com/ img: http://picasaweb.google.com/bg.branko twt: http://www.twitter.com/foxbunny/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
