KDE

warning: Creating default object from empty value in /home3/johnlayt/public_html/modules/taxonomy/taxonomy.pages.inc on line 34.

We have code

All going well, my code for adding Current Page and Page Set selection (aka Odd/Even pages) to Qt should now be up on gitorious for all to see and try out.  For those of you not wanting the hassle of compiling, here's a screenie:

Qt Odd Even Pages

The Gitorious branch is at http://qt.gitorious.org/~odysseus/qt/odysseus-clone/commits/current-odd-even.  I still have a few bits of polish to add, like disabling Page Set if Current Page is selected, and the initialisation is something I'm not 100% happy with, but it's mostly there and working.  I've been testing the last couple of days witout a real printer, but it should still be OK. I also haven't tested it compiles under Windows or OSX, so I'd be grateful to someone did :-)

So what does it do?

  • If you're on X11 / LPR and running an app that hasn't been modified, then you see nothing new.
  • If you're on X11 / CUPS and running an app that hasn't been modified, then you see the Page Set combo and CUPS takes care of the odd/even page selection.
  • If you're on X11 with CUPS or LPR and running an app that has been modified, then you see the Current Page (if set by the app) and the Page Set and the app takes care of the odd/even page selection.
  • If you are on OSX or Windows then you see nothing new (as yet).  Good news on that front is I have just seen a commit that moves Qt to using the Win2k print dialog instead of the Win98 print dialog, which should make adding these new features way easier. I still need help here though!

So how to modify an app?  Easy.  To enable the Current Page, just call QPrinter::setCurrentPage() with whatever your current page number is before you exec the print dialog.  To enable Page Set fully, just call QPrinter::setPageSelectionMode(QPrinter::AdvancedPageSelection) before you exec the print dialog, then make sure you either use the new QPrinter::pageList() method to get a list of the pages to render (the easy way) or use QPrinter::pageSet() to figure it out yourself (the hard way).

For reference, the newly added QPrinter public api is:

			enum PrintRange { AllPages, Selection, PageRange, CurrentPage }; // Just added CurrentPage
	enum PageSelectionMode { SimplePageSelection, AdvancedPageSelection };
	enum PageSet { PageSetAllPages, PageSetOddPages, PageSetEvenPages };
	void setPageSet(PageSet);
	PageSet pageSet() const;
	void setCurrentPage(int);
	int currentPage() const;
	void setPageSelectionMode(PageSelectionMode);
	PageSelectionMode pageSelectionMode() const;
	QList<int> pageList() const;
	

 

So, have a look, have a play, and let me know when you find my bugs :-)

[EDIT: Just a reminder this is a change to Qt so depends on the Trolls accepting it, but I'm hoping it makes it into Qt4.6 which will be out before KDE 4.4 so that's the up side]

What The???

I use Alt-F2 to launch apps all the time, so imagine my surprise when today when I suddenly got the following dialog the first time I launch a program:

KDE Vista

What is this, KDE Vista???

[Edit: Fixed the missing image]

The Reactive Desktop

This blog started at the last Akademy in Mechelen as some thoughts on the location aware desktop, what apps would benefit, and how we should be looking to use GeoClue to achieve this rather than rolling our own. But as I've written it I've been thinking about other concepts people have been discussing to the point that it has morphed into a disconnected ramble about the Reactive Desktop. It may not make a lot of sense, but one year later it's about time I posted it :-)

Just a quick note first about Geolocation services. At the moment Plasma has it's own Geolocation implementation. All credit to the guys who have been working on it, it filled a need and it is a fun itch to scratch and it is designed with a future switch in mind, but to me they do need to move to using GeoClue as a backend and to co-ordinate with Marble to move a Geolocation API lower in the stack (kdesupport?) where all apps can access it at all times, not just when using Plasma. A common low level Geolocation API with pluggable backends in the style of Solid and Phonon would become another Pillar Of KDE.

Right, onto the fuzzy blue-sky thinking.

A lot of the ideas I see floating around about the Location Aware Desktop are just at an application level, where an individual application responds to a change of location in an independent and un-coordinated manner, or actively queries the geolocation service when it needs to know the exact current location. These are ideas ranging from the panel clock automatically updating your timezone based on your location changing to konqi telling search engines where you are when searching for a restaurant, etc.

But at a higher level than that is the possibility of your entire desktop automatically adapting to your location when it changes. Imagine being at work with your laptop using your Plasma ‘Work’ Activity, you have open a bunch of work documents and apps, you’re connected to your work chat room, and Kontact is using your work groupware for e-mail and calender. You get to the end of the day, suspend your laptop and go home. On restarting your laptop at home, KDE detects that you’ve changed location to Home, so switches to your Plasma 'Home' Activity/Containment/Whatever with the NSFW wallpaper, saves your Work Session of open docs and apps for later, restores your last Home session with your Kate 'Hacking' session of several kdelibs source files you were working on, Konquorer tabs session with those dot and slashdot articles you were reading, starts Amarok playing with your chill-out playlist, logs you into #kde-devel, connects to MSN, and switches Kontact to your personal e-mail and calendar settings. When you go back to Work everything automatically switches back again.

While you could achieve that by the user going through every single app and individually configuring it to respond as required, that's just too much work. Why shouldn't we provide the user with a single place to configure this? To do that, I think you would need a broader, fuzzier concept of a 'Named Location' then an 'Exact Location' georeference at this moment in time. While you could then define Work as being within 1km of your office georef, Starbucks as being their ESSID, and Home as being anywhere else, you would then also have a way of manually switching locations when you have no Geolocation service available to automatically trigger the change or if you want to be in a different 'location' than where you are now (e.g. work from home).

And this is where my thinking gets a lot fuzzier as to how this would work in practice.

If you think about that a little more, we're no longer talking about being location aware, we're talking about application and desktop session or state management, with pre-defined application and desktop states being switched in response to an outside event. A Reactive Desktop and Applications.

OK, so we already have a lot of that with D-Bus and Solid events triggering application or desktop changes, but much of that is down to the app programmer to join up or the advanced user to script using D-Bus calls. Shouldn't we be letting our users decide what Events or combinations of Events trigger what Actions or state and session changes? If you look at PowerDevil, you have a great example of this sort of model. Shouldn't we have a more general model available where all apps and the desktop advertise a subset of the D-Bus Events they emit and what D-Bus or Session Management Actions they can have triggered, and then give our users a GUI to link these together? The switching to a Named Location state would then just be a special case of this. For example, if There's a cool app over in OSX that does something like this called Marco Polo, have a look it's quite cool.

There's a lot of stuff that would need to hapen first to lay the foundations here. Sorting out Geolocations services is a biggie, but other parts don't necessarily depend on that. Session management would obviously need to be greatly enhanced to enable you to save, edit and restore named desktop sessions, but also to have smart session switching, i.e. if an app is already running don’t close it and open it just change its state or config and geometry if possible. What else can people think of?

Some of the work needed as I see it:

  • Fix Geoclue to be fully Gnome independent (Inge has a patch?)
  • Add a Qt-only abstraction layer for Geolocation services (including Geoclue as one backend) to kdesupport
  • Add a KDE wrapper for the Qt abstraction layer (if needed) into kdelibs
  • Add a Named Location service to kdelibs or kdebase
  • Add improvements to desktop session management in kdebase
  • Add a KCM for Named Locations
  • Add support to apps and desktop
  • Apps to advertise their Events and Actions
  • GUI to allow users to link Events and Actions

Obviously this isn’t all thought through yet, there’s a lot that would need to be sorted out with the architecture and interactions of the components, and many things I’ve probably misunderstood completely about the KDE / D-Bus architecture that may make some things impossible to do, but I thought I’d float the idea out there and see if we can get some discussion going.

T minus 1

Flights? Check!

Hotels? Check!

Passport? Check!

Visa? I'm a Kiwi, we're harmless, so no-one demands we get one :-)

Flight and ID details registered with the Spanish authorities? Check! (Don't forgot this or you won't be let in! Your airline should have collected these at time of booking, or you can do it yourself online).

Sunblock? Check!

Told the bank so they don't block my cards? Check!

Power adapters? Check, check, check, and check!

Packing? Er, um, yeah, must get around to that... But what hardware/gadgets/toys do I take? Macbook, phone, GPS, MP3 player obviously, but what about my eee's? Keyboard? Controllers? 3G dongle? USB hub? Mini 3G wireless router? Kitchen Sink? Reference books on calendar systems? And if I'm hacking on printing stuff, then what about the printer... Yeah, Ok that would be overkill :-) Seriously though, if there's anyone from the Plasma MID project or something who needs access to an eee 701 or 901 for a few days, yell out and I'll bring them along. I will pack my 3Dconnexion navigator in case anyone from Marble or Krita or KStars wants to try hack support in for it. Oh, yeah, I suppose I'll need some clothes, but there's not much room left in the bag now :-).

Here's my personal agenda for the week, if you have an interest in any of these grab me and have a chat:
* Printing: getting what we need now into Qt, and planning a future with OpenPrinting.
* Calendar Systems: fixing our existing ones, adding some new ones (Saka, Julian, Bahai'i, etc), better supporting lunar-based calculations (KDEPIM need this), enhancing the Plasma widget and KCM.
* Currency Codes: extending KLocale to support ISO-4217 and with fully translatable names to actually be useful to the likes of KMyMoney and currency converter runners/widgets. If you work on these I'm very interested in chatting about your requirements.
* Localisation in general, if there's anything peculiar to your locale we don't support or don't allow you to adjust I'd like to know about it. Are there cross-platform issues that need resolving too? Do we play nice when running outside the KDE workspace?
* Geolocation: Not one I'm working on, but the community needs to talk about where it belongs in the stack and what solution to use. I've a blog about that coming up...
* Suntan :-)

Yippeeee! GCDS/Akademy here I come!

Self Referential...

So I type "windows print odd even pages" into Google to do a little research, and incrediably my blog post on "Advanced Print Ranges" from a couple of days ago turns up on the very first page of results as item 7.  You got to be kidding, does that make me an expert or something??? :-)  Of course, that's not as impressive as when I used to be the number 2 result returned for a search on "objectstar consultant", that sent a lot of job offers my way!

Bits 'n Bobs

The printing changes are going well, I have the Advanced Mode Current Page and Odd/Even in X11 working solidly, and the Simple Mode Odd/Even CUPS fallback hack is working fine except for one small glitch.  If you select to print a range from say page 4 to page 6 and then select Even pages, you do not get pages 4 and 6 as you might expect, but only page 5 instead.  Why?  Because CUPS thinks your page 4 is actually page 1 as it's the first page it has seen :-)  I need to hack in a cheat to either tell the app to produce an extra page at the start, or lie to CUPS and tell it to printOdd pages instead.  Other than that, I now have to move onto OSX and Windows support.

I'm currently building a Windows Qt/KDE dev environment in a Virtualbox (Windows 7 RC1 so it didn't cost a cent) so I can check my changes work over there and start on the dialog extensions.  The emerge tool the WinKDE guys have built is absolutely brilliant and a god-send, albeit a little short on documentation about what to do once the environment is set up :-)  I've also being dredging my way through the MSDN documentation on the Print Dialog and after years of hearing about how good the MS doco was and how we'll never win over developers until we meet that standard all I have to say is "Bullhockey".  Don't believe a word of the hype folks, it's terrible, at least for the printing stuff: TechBase, Qt, and the OSX doco especially are all way way better.  I'm now looking through some Windows FOSS code instead to see how others do it in the real world.  It looks like to get the Current Page and Odd/Even features in the dialog may be a Win2k and above feature using PRINTDLGEX instead of the Win95 and above PRINTDLG which Qt currently uses, which means quite some work to do.  But I could be wrong.

Does anyone have suggestions for the best distro for use on a Macbook5,1 late 2008?  I'm currently running openSUSE 11.1 which is getting a little long in the tooth and has issues with the 3D graphics and touchpad support and I'm finally tired of them not working right. I know the latest (K)ubuntu has far better Macbook hardware support and an active Mac community, but I'm reluctant after previous problems with the development environment and breakages over there.  Any suggestions for other distros with good Macbook support?

And I've finally received confirmation from the Travel Agency so:

Going To Akademy Logo

Don't forget peeps, update your travel details on the wiki and sign up for the tourist trip before June 28th and for any sporting activities, it would be nice to have some company on my "Footing" along the beach :-).

Advanced Page Range Options

This is the stuff I really want to see in Qt 4.6 and I would appreciate any assistance to get us there. Most other stuff we have work-arounds for, but this stuff can only be done by directly hacking in the heart of QPrinter and QPrintDialog.
* Current Page: This is the option in the Print Dialog to print whatever the currently selected page is in the Application.
* Page Set: This is the option in the Print Dialog to print either Odd or Even or All pages.
* Non-Continuous Page Range: This is the option in the Print Dialog to instead of just entering the From and To page number to instead type in a free text page range that may have gaps in the range, e.g. "3-6,9-13,15".

First a rough and ready explanation about how Qt does cross platform printing support. The underlying Qt print engine has backends implemented for each platform, so you paint onto QPrinter/QPainter and it then translates that into something the native Print System can print (ps/pdf for CUPS or LPR on X11, pdf for CUPS on OSX, GDI or whatever it’s called on Windows). The visible Print Dialog however is only implemented by Qt for the X11 environment, on Windows and OSX the native OS print dialog is called and the selected values are then passed back into QPrinter to be used by the app.

The big problem with adding these three features is that, unlike KDE3, QPrinter only tells the application the From and To page numbers to print, and all Qt and KDE4 programs have been coded to generate all the pages in that range to send to the Print System. The apps have no way of knowing that they must leave out pages in between, so any such features would in theory require all apps to be re-coded to use them and enable them in the dialog individually, which is not ideal. However, on Mac the Odd/Even page option does appear in the native Print Dialog, and works, so what's happening there? I'm assuming the application is still painting the full page range but Qt is quietly telling CUPS to only print the odd or even page set. Not optimal if you have a 500 page document to print over a network, but a solution that can be copied into the X11 dialog when it detects CUPS is being used instead of LPR. That gives us a level of backwards compatibility for X11 and OSX, but it’s not very nice and fails completely on Windows.

So here's a high level on how the full solution will work, largely cribbed from KDE3, but taking cross-platform and backwards compatability into account.

QPrinter: A new enum called something like PageRangeControl {SimplePageRange/AdvancedPageRange} which defaults to SimplePageRange, i.e. is the status quo. If set to SimplePageRange then the Print Dialog displays any range modifiers the current Print System supports, the Application generates all pages in the Page Range, and the Print System applies any range modifiers it supports. If set to AdvancedPageRange then the Print Dialog displays all range modifiers, the Application applies all the range modifiers to only generate the required pages, and the Print System does not apply any range modifiers.

QPrinter: A new pageList() method in QPrinter that will return the exact list of pages for the Application to print, taking into account the setting of PageRangeControl and all the possible range modifiers including reverse page order. If SimplePageRange then return a QList of all page numbers between From and To. If AdvancedPageRange set then return only those pages to be printed after applying the range modifiers.

Current Page: App must set the Current Page number via new QPrinter::setCurrentPage() method, then Print Dialog will display Current Page option. Will work seamlessly with both SimplePrintRange and AdvancedPrintRange. Not supported on Mac?

Odd/Even Page Set: If App sets AdvancedPrintRange or the Print System is CUPS (X11 or OSX) then Print Dialog will display Page Set option. Provide setPageSet() and pageSet() methods

Non-Continuous Range: In SimplePrintRange mode then we have two options, either it's unsupported on all systems, or we add support on X11/CUPS only by telling the app to geneate ALL pages in the document and then let CUPS select the pages.  In AdvancedPageRange then supported under X11 and Windows but not OSX.

X11: Full support for Odd/Even and Non-Continuous on CUPS, on LPR only if app chooses AdvancedPageRange. Support for Current Page only if app selects.

OSX: In SimplePageRange mode support for Odd/Even as per current.  In AdvancedPageRange mode support via Odd/Even via app selection.  No support possible for Non-Continuous and Current Page?

Win: Support for Odd/Even, Non-Continuous and Current Page only if app chooses AdvancedPageRange?

Apps: By default will carry on as currently, even if dialog detects print system supports some extra features.  If app wants to support extra features or be more efficient, then will set AdvancedPrintRange and use pageList().

Where am I at?  I have the basic Current Page and Page Set done on X11, and the Non-Continuous half done.

What’s left to do / What do I need help with?
* Add all PageRangeContol stuff
* X11 dialog to detect if using CUPS and enable SimplePageRange mode for Page Set and Non-Continuous
* Windows - How to add the Current Page, Page Set, and Non-continuous features to the Windows dialog and connect them back to Qt. I haven’t gone looking yet, but I believe these are standard features that the Win API provides calls for? Any Windows print gurus out there
* OSX – Confirmation that OSX cannot have Current Page and Non-Continuous. Where to hack Qt to not pass Page Set to CUPS in AdvancedPageRange mode.
* Git :-) Especially how the Qt build actually works when you have multiple branches on your local clone that inherit from each other, surely there would have to be separate build directories, does Git seamlessly handle switching those too?  My idea is to have a series of small branches adding each feature in turn to make review easier, rather than one giant patch set adding everything. My code is currently in svn, so I need to migrate it over and set it up right before publishing it.  There's going to be tutorials at Akademy about this sort of stuff, right???

That's a little sketchy in places, but I should have most of it finished for X11 by Akademy, and then the hard OSX/Win part starts.

P.S. Anyone else having problems with the Akademy offical Travel Agency, I put in an accomodation request a week ago and have yet to hear back.  Normal, or something to worry about?

P.P.S.  Something I've been meaning to point out for ages: the Qt Print Dialog (and every other Qt dialog / app) uses the KDE File Selector when running under KDE.  Thanks for this I believe go to Thomas Zander and David Faure back in the 4.1 timeframe.

Back again.

Hey, so really long time no blog, and almost as long no code.  Life, as you'll guess has been real busy, between a full-time job, uni, training (my first half-marathon coming up), and amazingly a full-on social life, KDE has struggled to compete for my time.  It's summer holidays now though, so no uni for a while which means time back on KDE.  It helps to have a place of my own now, a really nice apartment on Clapham Common in South London, where I can hack away uninterrupted (on that note, if you're passing through London on KDE-releated business and need a floor to crash on, drop me a line).  My first task is fixing up the Plasma Calendar which doesn't play well with the non-Gregorian calendar systems, and solving a few small bugs in the calendar systems in time for 4.3.

But enough of all that, I know what everyone's asking (or so it at least seems on the mailing lists/forums/bugzilla): what's the current status of Printing in KDE4?  Well, let me be clear here: KDEPrint is dead, not mostly dead, not just resting, but firmly staked through the heart and 6 feet under.  I know there are people out there who would like to see us have our own Print System and Print Dialog again, but they really don't realise the effort involved.  Anyone is more than welcome to have a crack, I’ll even help out with advice and pointers, but good luck as it's a huge and complex area that would take a team of several devs months of concerted effort to even get up to par.  I personally see little point in duplicating all the cross-platform Print Engine and Print Dialog stuff when we can hack on a Qt git branch and push the needed changes upstream for Qt 4.6 which is due out before any new KDEPrint could be ready.  I also see little point in duplicating all the Printer Admin stuff when most distros have now settled on a single config backend in system-config-printer which we can build on and contribute to.  Yes, there's restrictions in dealing with BIC and release schedules and we won’t always get our own way, but it relieves us of the ongoing maintenance burden, and all Qt apps on all platforms or all distros will also benefit.  Besides, in over a year of my tinkering with it no-one has stepped up to help out, so the resources just are not there to support a separate effort.  I don't even really want to be working on it, there's other stuff I find far more fun and fits better with my interests and very limited available time.

(Yes, I could eventually see us doing our own Print Dialog again, especially if the OpenPrinting effort comes together, but it would be built on QPrinter so we need to push the required features into there first).

So we need to focus on how best to achieve our goals by working with upstream, both Qt and system-config-printer.  I will be at Akademy all week working on it, if there's enough interest I'll get a BoF together to discuss a more co-ordinated effort, because relying on just me to get this done is a recipe for disaster (or at least a very long wait).

To start with I’ll post a series of blogs to cover things in more detail, what issues are still outstanding, how I see them being resolved, and what others can do to help:

* Printer Admin - The KCM module for Printer Configuration, and the Print Job Applet.
* Advanced Page Ranges - Adding Current Page, Odd/Even Page Set, and Non-Continuous Page Ranges to Qt
* Advanced CUPS options - Move all the KDE supported CUPS features into the Qt X11 Print Dialog
* Save/Restore Print Settings - Adding save and restore of current state to QPrinter, and direct support for this in the Print Dialog (a la OSX)
* File Printing - Yes, there is a way to hack X11 and probably OSX to do this, it's Windows that's the problem.
* Virtual Printers - Adding Print to Fax, Print to E-mail, Add Printer, etc directly in the Print Dialog printer selection combo box, and do we really want to?
* Page Previews – In-line previews in the Print Dialog, a la OSX.
* Utilities – kprinter and kprintfax.
* Other stuff - Anything else I can think of missing in Qt, e.g. full cross-platform support for apps adding tabs to the dialog, full cross-platform duplex support, fixing the CUPS properties dialog, etc
* The Future - The new OpenPrinting dialog, what has happened to that project???

So lets get the first one out of the way now: Printer Admin.  With Ubuntu and Mandriva both having adopted Red Hat's system-config-printer as their official printer configuration system, and at least Debian, Arch, Slackware and openSuse all packaging it, I think we can safely assume that it has a secure future.  Hey, if it's good enough for Til Kampeter to go with it instead of printerdrake, that's good enough for me.  Jonathon Riddell and the Kubuntu guys added a KCM and job applet in 4.2 and have put quite a bit of work into it for 4.3, so we seem to be well covered there now.  I know there are some complaints that it is very CUPS oriented and possibly doesn't play so well with LPR-only systems, but with every modern distro shipping with CUPS as the default print system, if you're one of the 6 people explicitly choosing not to use CUPS but still expect to use a modern desktop like KDE,  then I don't think it's a big ask that you have to manually configure your own printers.

Next blog, advanced page range selection, the stuff that people seem to be complaining about most (or is that persistance of settings?).

Dear Lazyweb

Being lazy here, but I suspect this will be quicker than trying to work it out myself :-)  I'm using dfaures's excellent scripts as detailed on techbase to build and run trunk in a local directory while still having a stable 4.1 desktop from packages.  It works wonderfully, execpt I can't seem to solve 2 issues.

 

1) When building kdeedu with the experimental Marble Python support turned on it tries to install marble.so to /usr/lib64/python2.6/site-packages/PyKDE4/, which I obviously don't want.  I've tried exporting PYTHON_SITE_PACKAGES_DIR as something local but that doesn't seem to do the trick.  Does anyone know what variable I do need to set?  This isn't a major issue now as it's now able to be turned off.

 

2) When trying to run the trunk startkde in Xephyr it fails, with the following being the apparently pertinant part of the log:

 

kdeinit4: preparing to launch /media/laptop/Programming/KDE/inst/kde4trunk/lib/kde4/libexec/klauncher
kdeinit4: Launched KLauncher, pid = 24785 result = 0
klauncher(24785) kdemain: Waiting for already running klauncher to exit.
klauncher(24785) kdemain: Waiting for already running klauncher to exit.
klauncher(24785) kdemain: Another instance of klauncher is already running!
kdeinit4: Communication error with launcher. Exiting!                                                                         

 

So it appears to be objecting to the KLauncher already running for my normal 4.1 desktop session.  Looking at the other build articles on Techbase, all the instructions are for running a KDE4 Xephyr session inside a KDE3 desktop and not a KDE4 desktop.  I'm sure I'm not the only one working this way, so leave me a comment as to what needs doing to get this to work and I'll update Techbase to share the love.

 

TIA!

KDE l10n Status Check

In preparation for setting up the locale files with the right working week values, I thought I'd do a quick check on our l10n status against the official ISO standard list and the UN list of recognised entities.  Of the 246 currently on the ISO list, we have locale files for 228  So who are we missing?

  • AQ Antarctica
  • BL Saint Barthelemy
  • BV Bouvet Island
  • GF French Guiana
  • GG Guernsey
  • GS South Georgia and the South Sandwich Islands
  • HM Heard Island and MacDonald Islands
  • IM Isle of Man
  • IO British Indian Ocean Territory
  • JE Jersey
  • MF Saint Martin
  • MP Northern Mariana Islands
  • RE Reunion
  • SJ Svalbard and Jan Mayen
  • SL Sierra Leone
  • TF French Southern Territories
  • UM United States Minor Outlying Islands
  • YT Mayotte

OK, so there's a fair number of UK, US, and French territories in there, and some very remote uninhabited islands that are clearly to be considered as part of their parent country for locale purposes.  Yet they are officially recognised to some extent and many have the various trappings like flags and limited self-governance.  Where to draw the line is tricky, but if you're a KDE user from one of these territories and want to make a case for inclusion, then I'm willing to listen.  Jersey, Gurnsey and the Isle of Man could make good cases, as could the more autonomous French Collectivities.  Anyone claiming to be from Bouvet Island will be ignored as not existing :-)

The notable one here is Sierra Leone which undoubtably should be included.  Another difference is we have an old locale code of TP for East Timor, when the official code is now TL and the official name is now Timor-Leste.  With the feature and string freeze kicking in tomorrow, it's probably a bit late to fix these now, but we'll have to sort it in 4.3.

Syndicate content