On Thu, 2007-04-26 at 19:55 +0000, orestis wrote: > So, for Greek: > > I'll stand by my choice of having more options in the > django.utils.dateformat. > > But, since Malcolm seems reluctant to change a functionality so basic > and simple,
Hold on... you're putting words into my mouth here. :-) As I wrote in the initial report, I simply don't have an opinion on a preferred solution yet. No reluctance, no enthusiasm, just lots of thinking about it. What I'm not prepared to do is rush to a decision. If it takes us two weeks or a month to come up with a workable solution, the world won't stop turning in the meantime. This is a hard problem, not because there are a lack of solutions, but because every solution has a potential downside and there are a number of different audiences affected: translators, developers (both core and third-party) and users. I am completely in favour of solving this problem. Partly because the majority of people on the planet have a first language that is not English, so we have some obligation to them, and partly because I get a kick out of being able to send friends in Sweden or China a screenshot showing a fully translated, accurate page that blows away anything they get from the closed source world. > maybe something can be put in localflavor, so that each > language/country can handle their own needs and peculiarities without > bothering everyone else. > > Maybe a "ldate" or "localdate" filter that: > > a) Tries to find an implementation in the current locale - localflavor > and passes the arguments there and > b) failing that, either gives an error message or returns the default > date format, using the current django.utils.dateformat > > This way we free the project administrators from unnecessary decisions > about matters they really can't judge as well and leave the current > functionality working as before. So that we're all thinking about the same set of problems, let me lay out the developer side of the issue here (as well as the perspective of somebody who has done i18n development for quite a few years, so I have some sympathy for the potential problems that arise for both translators and developers): (1) The fundamental reason this (date formats) is a problem at all is because we are attempting to construct grammatical sentences out of short fragments. A guiding principle in creating translatable strings is to create complete strings as often as possible because constructing sentences from fragments is *very* locale specific. The reason we cannot use full string extracts here, of course, is because these fragments go together to create every date in the year. 366 of them! Multiplied by two or three different forms. So we need to work out a solution that is based on building from fragments. (2) Ending and even whole word changes due to the role played by a word in a sentence (object, subject, noun, adjective-form, ....) is common in many languages, but not so much in English. Unfortunately, because of the family tree of languages, the necessary changes vary a lot based on locale. Even within the Indo-European languages there are a lot of variations. Trying to catalogue all variations on our particular problem phrases here might be challenging. Or it might not be that complicated for the case at hand. This suggests that pushing more intelligence down to the locale-specific functions is not a crazy approach (again, I have no opinion yet, I'm just laying out the various sides of the problem). (3) Adding lots of extra format markers to indicate objective, subjective, dative, possessive and other sentence roles for nouns is something that has been proposed, although I'm not sure if we will get a clash between the role to assign to a word in different, quite separated languages. This does add to the burden of the author. I (as a software developer) would now need to mark up my previously relatively simple date string in a way that I probably won't be able to understand without reading a reference page when I come to debug it. I can remember the common POSIX date format strings, because I use them a lot. I cannot remember the PHP ones (which we use in Django templates), so I have to look them up each time. Multiplying the possibilities still further starts to get really challenging. A PHP developer or web developer is probably going to have a slightly different point of view (they will be more familiar with Django's template date format strings), but they will also be dragged into unfamiliar country when we add new format markers. Not a death blow for this idea, but something to bear in mind. There's also the side-effect that I -- and people like me -- probably will not be able to get the markup correct for a date string on the first one, two or six tries. That's pretty normal for complicated i18n markup, though, and translators and other knowledgeable people can usually help to fix the odd cases. -- end of summary -- Please feel free to add any points that I may have missed here. I think the above three are a summary of all the things floating around in my head. I thought it was originally going to be about 10 points, but when I merged all the similar ideas, there are only a few big issues. So we need to find a way of allowing translators to mark up strings in each of the forms required for their language and substituting in the right value at localisation time. Ideally, without a huge impact on content authors (although some impact is unavoidable, so let's not be too restrictive). The solution should definitely allow for dynamic (on a per-page request basis) changes in the language used to present the page, although I don't think any of the suggestions so far have made that impossible. At the moment, I think it might be productive to keep hearing suggestions. Basically, "no idea is too stupid" for a few days. I suspect there might be a good idea that nobody has mentioned yet. How about we leave this thread going for a little while to give people a chance to think and then look at what we've got. I'm not going to contribute much unless I see anything that is clearly technically infeasible. This is a hard probem. I do not know of any truly perfect solution in other projects, either. 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
