Issue 2133 - Allow to specify default translation inline in pages rather than in a separate file

cms/sources.py

Index: cms/sources.py
===================================================================
--- a/cms/sources.py
+++ b/cms/sources.py
@@ -37,17 +37,17 @@ class Source:
 
     checked_page = page
     if config.has_option("locale_overrides", page):
       checked_page = config.get("locale_overrides", page)
 
     if self.has_localizable_file(default_locale, checked_page):
       if not self.has_localizable_file(locale, checked_page):
         locale = default_locale
-    elif self.has_locale(default_locale, checked_page):
+    elif self.has_page(checked_page):
       if not self.has_locale(locale, checked_page):
         locale = default_locale
     else:
       print >>sys.stderr, "Warning: Link to %s cannot be resolved" % page
 
     if page == default_page:
       page = ""
 
@@ -69,18 +69,25 @@ class Source:
     return "pages/%s.%s" % (page, format)
 
   def list_pages(self):
     for filename in self.list_files("pages"):
       root, ext = os.path.splitext(filename)
       format = ext[1:].lower()
       yield root, format
 
-  def has_page(self, page, format):
-    return self.has_file(self.page_filename(page, format))
+  def has_page(self, page, format=None):
+    if format is None:
+      from .converters import converters

[Sebastian Noack, 2015/03/12 20:33:46]

From PEP-8: "Relative imports for intra-package imports are highly discouraged.
Always use the absolute package path for all imports. Even now that PEP 328 [7]
is fully implemented in Python 2.5, its style of explicit relative imports is
actively discouraged; absolute imports are more portable and usually more
readable."

[Wladimir Palant, 2015/03/12 20:57:02]

Relative imports actually made moving this out of sitescripts simpler ;)

Either way, I know what you think about relative imports. However, they are used
consistently across the CMS. So I'd rather keep things consistent and replace
relative imports in a separate change.

[Sebastian Noack, 2015/03/12 21:08:19]

Fair enough. I'm looking forward that change. :)

+      return any(
+        self.has_page(page, format)
+        for format in converters.iterkeys()

[Sebastian Noack, 2015/03/12 20:33:46]

Nit: Do you know that you can lazily iterate over the dictionary itself,
yielding its keys? So there is no need to call .iterkeys() here.

[Wladimir Palant, 2015/03/12 20:57:02]

Yes, I know that. However, I prefer to keep things obvious.

[Sebastian Noack, 2015/03/12 21:08:19]

So you would also use ..

for (let key of Object.keys(o))

.. instead ..

for (let key in o)

.. in JavaScript? ;)

[Wladimir Palant, 2015/03/12 21:15:27]

These constructs aren't actually equivalent. Besides, the for..in loop is meant
specifically to iterate over properties of objects, it won't do anything beyond
that. A Python loop on the other hand can iterate over all kinds of things, you
actually have to know what kind of object you have there. It's the same with the
for..of loop in JavaScript and I'm not sure I'd approve any non-obvious use of
it (meaning: not an array).

+      )
+    else:
+      return self.has_file(self.page_filename(page, format))
 
   def read_page(self, page, format):
     return self.read_file(self.page_filename(page, format))
 
   #
   # Localizable files helpers
   #