Yes, DefaultLanguage could be used like this, but it is much better to set the
system locale correctly.

For the common case of needing the system locale to correspond to the language
and locality of the physical location of the user, system-config-language can be
used to set this.

For the less common case of wanting the system locale to be different from the
language spoken, some other locale tool may be required, although your
suggestiong of altering DefaultLanguage might be a stop-gap solution.

What I would like to do is add a screen to the troubleshooter (i.e. the dialog
you get from Help->Troubleshoot) to find problems that might be caused by the
system locale being incorrect, and suggest solutions.

There is a question mark over how to identify situations where the system locale
is incorrect and causing a problem.

One possibility would be to make it compare the system locale (from
/etc/sysconfig/i18n) to the current locale (from the user's environment) -- if
they use different paper sizes, this might suggest a cause for problems.

Another possibility would be to compare the system locale (from
/etc/sysconfig/i18n) to a chosen print queue's paper size.

As for possible solutions, it could suggest selecting
System->Administration->Language from the menu (hopefully
system-config-language) is installed, or we could even have something like this:

[British (A4) v]   [Set Print Locale]
 American (Letter)
 ...

I think your assumption is wrong, you seem to be building upon the fact 
that the end users has his system locale incorrectly configured while I believe
it's the other way around, user(s) choose to have their OS installer default
language ( which in our case is en_us ) and only alter their keyboard layout.

On top of that, whether my assumption is correct or yours, we have mobile users,
users that travel from one continent to another which might use different media
sizes. 

For example let's say you would travel here to Iceland to hold a lecture
in developing user application and you need to printout some handouts you would
not want to alter your system local on your laptop just to be able to print on
A4 now would you?

There have been some far out suggestion tying the media size to "time zone"
which is just absurd ( At least as I see it ). 

If I was to travel around the world, I would be keeping my laptop on my time
zone while using an clock applet the supports multiple time zones.

The main problem here is that application should not be getting their paper 
size at all from system local. Application should either get their overall
printer settings from their printer back end ( or their window system which then
gets it settings from the OS's printer backend ), which in our case is cups or
they should just send raw print job to the printer backend and he takes it from
there.

Printer backend ( arguably ) could take his default settings from system local.

If you are going to create a troubleshooting wizard you build that wizard upon
cups and printer related problems until everybody can settle on one
place to get their printer settings from. ( Which should be cups in our case )

Trouble shoot the printer it's self (locally or network connected printer which
you can log onto, check for ink, paper, firewall the usual stuff ).

if its a network connected (cups) print server ask or offer to send an email to
the printer admin that he has incorrectly configure the print server with text
on what would be the correct way of setting up his printer.

For example one classical could not retrieve ppd file from print server, up pops
an msg box that offers to send the printer admin email which contains an 
direction on how to setup CUPS-Get-PPDs directive.

Indeed there is an question mark over how to identify situations where the
system locale is incorrect and causing a problem.

Trying to troubleshoot system local brings in to many variables, on top of my head.

A) Application developers cannot agree that getting their media size from
   the system local is the right thing to do. ( And I aggree and say get it
   from the printer backend ). Hence the risk is the troupleshooter suggest to
   the end users that he should start messing with system local settings and
   and he ends up messing up printing settings for other applications and his
   system local.

B) Which one are you going to check and ask the user to change? 
   The systems default or his?

C) B - with more then one user on the system.

D) B and C with different language settings.

I think there are several issues getting muddled into one here.

Regarding the troubleshooter -- this application already exists.  Try
Help->Troubleshoot from the main system-config-printer window.  This bug report
is a reminder to me to add in some locale checks to that troubleshooter -- at
the very least, reporting the system locale in its debug output.

There are several types of "default page size", and it is important not to get
them confused:

1. When a USB printer is connected, the queue that is automatically created for
it is given a value for its PPD's DefaultPageSize attribute.  This is the
"default default": the default value that new print queues get for their default
page size.  CUPS sets this based on the system locale, i.e. the locale set in
the environment of the cupsd process. (This is the default I have been talking
about in previous comments.)

Note that locale is absolutely the correct mechanism for this.  Locale is not
just about language, but also numeric display, currency, paper size, etc.

2. A particular CUPS printer queue has a default page size given by its PPD's
DefaultPageSize attribute.  This can be overridden by the application when it
submits a print job, and some printers can select different input trays
depending on the required page size of a particular job.

This page size will be used when converting some file types to printable
content: for example, when printing images directly.  It may even be used to
convert all jobs to the correct page size if only one is available.

3. When an application creates a new document, it may have an inherent page size
associated with it: for example, which page size do you get when starting
OpenOffice.org Writer?  Additionally, some applications may allow a new document
to be formatted for a particular printer, and fetch the page size and margins
from its PPD.

So, in answer to your question about mobile laptops: if someone has a laptop
with a default system locale of en_US (i.e. US Letter paper), and connects it to
a network in an A4 locale to print a document they have to a network CUPS queue,
that queue will convert their US Letter pages to A4 size.

If they want to print to (for example) a Windows print share, they can create a
new queue for this but it will have a default page size of US Letter (due to
default number 1 above).  So as the next step they can just change the default
page size of that queue (i.e. default number 2 above) to A4.

If they want to create a new document and have it use the correct page size,
they really need to set their locale to be correct, or use libpaper, or some
other mechanism -- whichever they choose, that's outside the scope of CUPS and
system-config-printer.  My own opinion is that the locale should be used (the
user can override the system locale for this), since that is precisely the kind
of thing it is for.

The troubleshooter now reports locale settings in the diagnostic output, but
does not suggest any changes to the user.