ticket,summary,type,release,owner,status,created,modified,_description,_reporter
4291,"default language, according to users capabilities",enhancement,0.10,Shun-ichi Goto,new,2008-12-16T21:42:10+01:00,2008-12-16T21:42:10+01:00,"#3380 added support for multiple languages, which also can be set with a ""default"" option. 

suppose there is page !InEn written native in english, and !InDe in german. would it be possible to store ""de"", ""en"" as spoken languages, and the plugin displays !InEn.en and !InDe.de automatically by selecting default? 
suppose there is page InEn? written native in english, and InDe? in german. would it be possible to store ""de"", ""en"" as spoken languages, and the plugin displays InEn?.en and InDe?.de automatically by selecting default? 
",rupert thurner
4225,"Improve handling of ""extension-less"" pages",enhancement,0.10,Shun-ichi Goto,new,2008-12-08T16:37:23+01:00,2008-12-11T15:29:22+01:00,"It would be nice to have the handling of ""extension-less"" pages (i.e. ""Default-pages"") improved. At the moment, a wiki page without language prefix is just listed as ""default"". My suggestions depend on the page type - and an additional entry for the `trac.ini` to either use the current way - or the improved way as described here:

'''user_pages''': Instead of ""default"", `wiki.default_lang` should be used (if set - otherwise stay with the current behavior).

'''system_pages''': Here we usually don't have language-specific versions, but all of these pages are using the same language. Since this language is not necessarily be identical with the `default_lang`, but still may differ (e.g. if a localized version of Trac is used), the ""language"" part could simply be omitted.

To be more safe (especially for the system_pages), the before mentioned `trac.ini` entry could be duplicated: one for the user_pages, one for the system_pages. Examples for the values could be: ""default"" (literally), ""system"" (use the default_lang defined in the `wiki` section), or a 2-char language code - where the latter makes not too much sense, since it would be identical to default_lang in 99% of all cases I can think of, so ""default"" and ""system"" should be sufficient.
{{{
[wiki-negotiator]
system_pages_default_lang = none # no language part to display; alternative: system|default
user_pages_default_lang   = system # use wiki.default_lang; alternative: default
}}}
If `system_pages_default_lang` is set to `none`, and a system page with language variant is encountered (who knows?), simply fall back to the current behaviour ''for that page only''.

The value `system` is to be preferred over a explicitly given language code, since this avoids double declaration (and a probable cause for mistakes).",izzy
1756,[patch] export page/lang suffix variables to other plugins,enhancement,0.10,Shun-ichi Goto,new,2007-07-09T12:39:42+02:00,2007-07-09T12:39:42+02:00,"{{{
#!diff
Index: wikinegotiator/negotiator.py
===================================================================
--- wikinegotiator/negotiator.py    (revision 2412)
+++ wikinegotiator/negotiator.py    (working copy)
@@ -32,6 +32,9 @@
             orig = req.args.get('page', 'WikiStart')
             # set altered page name
             page = self._decide_page(req)
+            name, lang = self._split_lang(page)
+            req.args['page_name'] = name
+            req.args['page_langsuffix'] = lang
             if page != orig:
                 req.args['page'] = page
                 self.env.log.debug('Negotiated: %s' % page)
@@ -39,7 +42,6 @@
                 # page is selected.
                 # TODO: I don't know we should set default language
                 #       for base page.
-                _, lang = self._split_lang(page)
                 req.send_header('Content-Language',
                                 lang or self._default_lang)
             # always send Vary header to tell language negitiation is
}}}

it would be nice if we can export to other plugins that may want to use is. tracnav is one of those.",phpxcache