You'd probably do this with a magic translated string like
default:LTR.

Here is a patch. 

Do you think year_left should be explicitly settable in addition to
the magic "calendar:YM" string technique ? 

Created attachment 16346 [details] [review]
patch

* How does this interact with RTL flipping? I'm thinking
  that the interpretation of MY/YM should be dependent
  on the current widget direction. 

  It seems easiest to do RTL flipping at the same time
  as doing this?

* There are some misplaced braces

* I'd really like to see things cleaned up to avoid duplication
  of calculations between realize() and size_allocate()
 

I actually thought of this as being the "RTL-flipping" for GtkCalendar.
Do RTL speakers expect the calendar table itself to be flipped ?

Created attachment 18465 [details] [review]
better calendar flipping

I found that GtkCalendar already did RTL flipping, but it had some issues:

- arrow key movement was flipped as well
- week numbers were not flipped
- header was not flipped

I've fixed these and added my header-flipping-by-magic-translation 
on top of it. I guess this is what you meant by  "MY/YM should be
dependent on the current widget direction".

	* gtk/gtkcalendar.c: Complete the RTL flipping support for
GtkCalendar, make it
	possible to flip the headings using the "magic translated string"
technique. 
	Translators, note the comment in gtk_calendar_init() explaining this.

As I comment in bug #87977 :
----------------
I have a problem with this patch.
I have:
LANG=en
LC_ALL=es_ES

That's because I want to read the strings of the programs in its
original english, but I want other formats (Numeric, monetary, time)
set to spanish.

The days of the week are shown correctly in spanish, but the week
starts on Sunday, as opposed to spanish time format, that begins on
monday.

A friend told me that you are not using nl_langinfo() to discover the
time properties, because is not portable, and using instead a strings
translation method.

I think it could be solved using the strings translation method, but
using as LANG the language set in LC_TIME, in spite of the original
LANG setting of the user.

In that way, one could use LANG=en and LC_TIME=es without problems.
----------------

This patch could be affected by the same problem, having diferent LANG
and LC_TIME settings.

Hmmm, maybe actually a valid use for dcgettext!

Indeed. I'll try dcgettext for this. Are there any systems with 
gettext, but without dcgettext, or do they always come together ?

I tried this:

+++ gtkcalendar.c       2 Mar 2004 01:37:12 -0000
@@ -706,17 +706,18 @@ gtk_calendar_init (GtkCalendar *calendar
    * so if you have a default text direction of RTL and YM, then
    * the year will appear on the right.
    */
-  year_before = _("calendar:MY");
+  year_before = dcgettext (GETTEXT_PACKAGE, N_("calendar:MY"), LC_TIME);
   if (strcmp (year_before, "calendar:YM") == 0)
     private_data->year_before = 1;
   else if (strcmp (year_before, "calendar:MY") != 0)
     g_warning ("Whoever translated calendar:MY did so wrongly.\n");
  
+  g_print ("calendar:YM %d\n", private_data->year_before);
   /* Translate to calendar:week_start:0 if you want Sunday to be the
    * first day of the week to calendar:week_start:1 if you want Monday
    * to be the first day of the week, and so on.
    */
-  week_start = _("calendar:week_start:0");
+  week_start = dcgettext (GETTEXT_PACKAGE,
N_("calendar:week_start:0"), LC_TIME);
  
   if (strncmp (week_start, "calendar:week_start:", 20) == 0)
 

but unfortunately, it doesn't work. straceing testcalendar reveals
that it actually tries to open 
/usr/share/locale/de_DE/LC_TIME/gtk20.mo
now. So in order for this idea to work, I have to at least
link LC_MESSAGES to LC_TIME. Doing that makes it work, more or less.
It also reveals that strftime apparently also uses LC_TIME for the
month names, since they change as well. Doing this more correctly
would require us to split messages again, this time by destination
category.

I think we should consider using nl_langinfo() on systems where it provides the
information, and fall back to the magic translated string.

closing out old bugs