I have read Fredrik Haglund's blogpost http://blog.fredrikhaglund.se/blog/2010/04/15/how-to-fix-alphabetic-sorting-of-pages-in-episerver/ discussing alphabetic sorting (where a comment from Fredrik concludes that the database solution is not useable).
Intuitively, I find that the sorting SHOULD really work according to the sorting rules for the locale the page is viewed for; e.g. viewing a page in Swedish should result in Swedish sorting, viewing a page in Norwegian should result in Norwegian sorting (which is slightly different!) and so on...
The site I'm currently working on is running CMS R2, and because there are relatively few items to sort, I've chosen to sort manually (by sort index) instead of alphabetically - but I feel that this is not a very good solution in the long run.
* If I only have a few pagetypes with lists; would it be a good idea to override the GetChildren() method on the relevant pagetypes? (Given that the lists are relatively short, would this have much impact on site performance?)
* Is this problem still existing in EPiServer CMS 6?
* If yes above; are there any plans to correct this behaviour in future versions?
This bug was caused by the introduction of database level paging for page listing in EPiServer CMS R2. Since the pages are already sorted and paged in the database the only sorting that is possible is the current database collation. In EPiServer CMS 6 this issue is mostly adressed with an additional sorting in the application level. This sorting is always applied when all pages has been fetched from the database which often should be the case. If you really use the paging functionality in the database then sorting will not appear so it's mostly up to the template to decide what is most important: Database paging or pages sorted according to the current content language.
Ps. Perhaps some might say that it should be possible to send the current culture to the database and convert it to a collation. Have in mind though that sorting needs to be applied after language selection rules have been applied (like fallback and replacement language rules) which would mean that this really tricky logic needs to be duplicated in the database layer. Ds.