Translation of short strings

Catalan also uses two-three letters for weekdays abbreviation and they are not necessarily the first characters:

Dll (Dilluns)
Dmt (Dimarts)
Dmc (Dimecres)
Dj (Dijous)
Dv (Divendres)
Ds (Dissabte)
Dmg (Diumenge)

So I don't thing even this patch would help us. Wouldn't be easier to have a setting for this?

I don't want to eliminate the possibilities of being able to use the first letter or the first two letters, but for the abbreviation we can go back to a regular translation method used in core. In D6 core has a special flag for the full month name to distinguish it from the abbreviation.

Can you re-roll the patch to work that way?

In other words, I want the options to be :

1) First letter of full day name
2) First two letters of full day name (for countries where the first letter is the same)
3) Abbreviation, however it looks for each language
4) Full day name

I misspoke above about the core method, that is for month names, not day names. I'm not sure what core is doing about day name abbreviations. Can someone check?

You can't make assumptions about what order the days are in, they will change depending on the way the site is set up, and even if the traditional calendar display is to show Monday first in these countries, we support alternate first days, so doing something like a string of letters with pipes won't work.

My plan is that we do literal 'First letter' and 'Second letter' options for all languages so they are available where they make sense. Those options would be exactly what they say, the first and first two letters of the name. Where they don't make sense, you wouldn't use them. In the USA, one-letter abbreviations are used a lot and are nice for tiny little calendars. In some languages you can't use the one-letter abbreviations, so we have the option for two letters. Where neither of these work, we will have an option for the regular abbreviation, whatever that is. Each calendar can use whatever works best for their situation.

In other words, I don't assume that all of these options will make sense for all languages, but the options will be there for the times when they do. So the only things to be translated would be the abbreviation and the full name. The one and two letter options will be created automatically from those strings.

I think it makes sense to have a one and two first letters options for the countries that would use them. A third option for a custom abbreviation would be then helpful for other countries.

As the module author I can see no way that you could create a piped array of day names where the code would have any idea what value to use. When you're translating an individual day name the translation function will look for a translation for exactly the string you input, if you input the whole list, how will it know which value to pull out? It just won't work. We need a separate translation for each day and day abbreviation.

The only place 1 and 2 letter shortcuts are used is for calendar day headings, and you can select if you want to use that in the calendar settings, everywhere else we use the regular day abbreviation. So I repeat that I see no need to 'fix' the way of handling first and first two letter abbreviations. The calendar settings explicitly say that this is what they are, so if they don't make sense the admin would have no reason to select them. And they're not used anywhere else.

But please see that we already have a thread about creating a new method of localizing date formats and we now have this discussion duplicated in too many different threads.

I agree we need a different way of doing the weekday abbreviation translation, so we need a fix for that specific situation. I'm assuming core already has a way of doing this, and I asked above for someone to find out how that is done. If core is not doing that, we should use something like the core method of handling month full names and abbreviations for the day abbreviation. That makes the abbreviations translatable and appropriate for the language.

Didn't find out the way core handles this case but I'm using the following workaround: I changed default value of $length=-1 in function 'date_week_days_abbr' and then take A. translated abbreviations if $length has default value or B. substring abbreviations if function is called with defined length. So module authors can decide which way to go for each case the design on calling this function with or without length parameter.

Just wanted to contribute my 2 cents about Hebrew. (Since I tried date_popup today and found out it can't currently be used).
In Hebrew, similar to what robertgarrigos said about Catalan, using the first letter of the translated makes no since, because 4 of the weekdays begin with the same letter. There is however a 1 letter abbreviation that is commonly used, where the days Sunday to Friday are abbreviated by the beginning letters of the alphabet, and Saturday is abbreviated with its first letter.
In addition, 3 or 2 letter abbreviations are never used.
Therefore, I think that Pancho's suggestion of letting the translators decide how to translate each of the abbreviations independently can work well for Hebrew, as we could just translate all 2 and 3 letter abbreviations to their 1 letter counterpart.

Changing the title a bit, also we need to find a fix for translating 'second' that doesn't get confuse 'second' as a date part with 'second' as the order of things that happen.

Joining :-). #347666: "Second" produces translatable string collision with panels module has been marked as a duplicate of this issue.

One more issue, 'Repeats' is used as a menu label for tabs and also in the description of how often a date repeats, and we need to differentiate those cases. Plus the handling of a description parsed out of the RRULE values is generally hard to translate and needs some re-thought.

I'm playing around with some of the things suggested in #334283: Add msgctxt-type context to t() to see if I can create a system to handle our short string problems.

Although I originally dismissed the idea of providing a pipe-delimited string of the abbreviations, I now have an idea on how that might work as another option. I could create long, pipe-delimited strings for each set of abbreviations which could be translated and then instead of wrapping the abbreviations themselves in t(), I could create a custom function that would explode the values to grab the right substring out of that long translated string. I have to see if I can actually get this to work, but I think it has potential. And apologies to Pancho if that's what he meant all along and I was just not understanding.

Here's what I'm planning to use. Can someone try this out and make sure you are able to translate those strings and get them to work in date_format_date(). There are other places in the code that I will use this, but I want to see if the basic system looks like it is working, so this patch just uses the new translation strings in date_format_date().

I did some more work to this (some of the logic wasn't quite right, cleaned up some strings) and I think it works pretty well. It should be a big win for translators because it not only gives you good context for the strings, it also greatly reduces the number of strings that need to be translated. Instead of a string for every variant of 'Year' and 'Month', and 'Day', a single string with all of them.

I'm committing changes to Date and Calendar. The .pot files will need to be updated, but I will hold off on that until I find a fix for the other issues (if I can find one). But this takes care of all the problems of handling abbreviations.

The main remaining translation issue was the problem translating the repeating date description. I reworked the strings to combine the smaller parts into longer, more meaningful, strings and tried to add more context to the strings. I realize that there will be languages which need a completely different word construction where this still won't work right, but I think it is flexible enough now to work in many languages. When we find languages where it doesn't work you can post an issue with the specifics of what you get vs what you should be getting so we can further tweak the code.

I've committed some more fixes, tried creating new .pot files to see how things look there, and I think it is working well enough that I will mark this fixed.

Next I'll try to create new .pot files (I already see that creates some error messages I need to address) but that is another issue.

As I use the date_php4-module, I think I've found a few minor bugs introduced with the new translation system.

But the first part of my patch, that deals with date_api.module, looks like it is independent of PHP-version. It should even appear if your site is in English: t($c) will evaluate to t('e') or t('T'), so you just see an "e" character in formats that should print the timezone name or "T" instead of the abbreviation. At least I saw the 'e' in my translated strings.

In date_php4.inc, translated versions of day names were returned, which causes the new outer layer for translation to give empty strings. (I guess the old version passed the erroneously translated values through so you did not notice that they were translated at a too early stage.) The $c == 'D' case in date_format() has not really been tested, since date_format_date() uses its own wrapping to handle translation of that case.
There were also two lines where $date was used instead of $date_string for the output.

It would be nice if someone on PHP5 could confirm that the patch does not break anything.
Oh, and the diff is rolled against the dev tarball of 2009-Mar-09. I named the file after the current date, which may be confusing.

@emok, you are so good at finding these little problems :) In testing this I found a couple other small fixes needed to display timezone names correctly. Fix applied to both the D5 and D6 versions.

I just downloaded your Date module and have the same issue. I live in germany and it has to be Mo, Di, Mi, Do, Fr, Sa, So. Instead its Mon-Son. What must I do, I followed the discussion here, but I could not see any workaround. I am using PHP version 5.2.0

Yes, I'm having this again. The calendar block prints only the first letter of the day, even the translated string contains two letters for each day. am I missing something?

Please don't re-open a two year old issue for a newly discovered problem. If you are seeing a problem that is new or which seems to have re-surfaced ('I am seeing this again'), open a new issue with details about how to reproduce the problem.

BTW, things like whether the calendar block uses the first letter or two letters or three is controlled in the calendar style settings for the calendar view -- a calendar issue.