We need a way of making meta-pages multilingual, transparently. I propose the following:

To mark one page as a translation of another, mark it with

 PageTranslation <WikiName here>

This should cause both pages prominently to link to each other, but more importantly it should make links to one page pick the correct translation for the language the user has selected as their native tongue (where available), or display all choices where the user hasn’t (or their native tongue is not an option yet).

Technical note: PageTranslation is reflexive, symmetric, and transitive: an equivalence relation.

This solves the issue with PageClusters, as we can now use

 (on PageFaisceau) PageTranslation PageCluster
 (on PageTranslation) PageFaisceau ExperimentalTechnology

It also solves its own problem, as we can use

 (on TraductionDePage) PageTranslation PageTranslation
 (on PageFaisceau) TraductionDePage PageFaisceau

Since PageTranslation is symmetric, we could equally have used

 (on PageTranslation) PageTranslation TraductionDePage
 (on PageCluster) TraducionDePage PageFaisceau

The system also works as a reminder to keep translations up-to-date.

I leave the details up to Alex.

ChrisPurcell (this text is PrimarilyPublicDomain)


There is a real translation extension for Oddmuse, which will link to the original page and tell you whether the translation is out of date or not. However, that implies the notion of “original” and “translation” which most likely won’t happen. It seems far more probable that the English and German communities will create a slightly different site – only occasionally will concepts be translated directly. Note that for readers looking for information, the the site-wide multilingual search will help them find information in any language. And often when bilingual people find an interesting discussion, they will just contribute in the appropriate language, without creating a literal translation of the page. This is why I assume that for a site such as CommunityWiki, the linking to “translations of this page” will very likely be of little use. But then again, there’s not much experience anyway… On the EmacsWiki, some administrative pages got translated, but the few non-English pages are independent from the English pages, describing pages a German user wrote in German, documenting some code of his, for example. The Oddmuse manual on the other hand is different, because there, an attempt was made to translate “the entire manual”. But at the moment there are no translators anymore, so I’d be happy for any translation, no matter how small. – AlexSchroeder

PageTranslation is there for the main pages that need to be communal because they’re about the engine we work over; pages like PageClusters, or PageTranslation, or HowTo. It gives the engine enough to allow a decent, workable alternative to clunky syntax hacks. To create a new banner for a new language, you just link in a new translation for the pages, and the engine can figure the rest out (if you program it to). You no longer need new scripts installed when a new language crops up. It gives power to the community, and I don’t see a better way of doing it. – ChrisPurcell

I’d like to postpone a decision on this. A new language usually requires user interface translations on the server anyway, unless you have publically editable config pages, so until we actually have some non-English contributors, we can just as well wait. – AlexSchroeder

I was wondering whether everything - including the language autodetect feature of RecentChanges - could be boot-strapped from the PageTranslation feature, plus some canonical English page-names. Effectively, we are creating config files within the Wiki structure.

In the meantime, I suggest we keep the PageCluster situation as it is described above, assuming you are now happy that it will scale to multiple languages. – ChrisPurcell

Page alias: PageAlias

The following syntax is used to declare a page alias:

 Page alias: FooBar

This would be equivalent to the following default Oddmuse rule for permanent anchors:


I’d like to get a decent, consistent syntax for all these things, rather than relying on symbolic kludges that get more convoluted with every feature. Debate is expected! – ChrisPurcell

Yeah, that should be easy to add, except for one thing: The rule must not match an existing rule (and “PageAlias” per se already does). The CSS for permanent anchors is unusual: It formats them as h2 headers. I kept “Page alias:” and linked it to “PageAlias”. Dunno if that is better or worse. – AlexSchroeder

PageAlias already matches an existing rule? Ah, what? (Don’t tell me: page clusters.) – ChrisPurcell

Wrong. :)PageAlias: FooBar?” will be parsed as the local link PageAlias, plus more, and therefore “PageAlias” will never be seen by extensions in the config file. – AlexSchroeder

Your redirect code seems incorrect. It redirects to "community?PageTranslation#PageAlias" not "community/PageTranslation#PageAlias.

I see; that could be fixed. But why “incorrect?” It works, as far as I can tell. I just didn’t move all instances of ?foo to /foo (yet). – AlexSchroeder
Word choice, nothing more. I assumed you would want consistency of link format for pages likely to be permanent anchors; hence the syntax mix is a bug.

As to why PageAlias doesn’t work: I think I’d need to understand your engine a lot better to understand what you just said. – ChrisPurcell

Heh. A simplified answer is this:

    sub ApplyRules
      while true
        if wikilink then print pageoreditlink
        elsif freelink then print pageoreditlink
        elsif ...
        elsif customrule then print the result
        elsif word print word
        else print a char
        break if end of text reached

So when we’re parsing “And this is a PageAlias: FooBar?” then this prints “And” space “this” space “is” space “a” space pageoreditlink ”: ” pageoreditlink, because the test for wikilink happens before customrule matches the current “position” in the text. – AlexSchroeder

So how did PageCluster work when it did? – ChrisPurcell

When the default pattern and the alternative “Page alias: …” will not match “wikilink” and “freelink” – so our custom rule gets to match it first; and the successful match will prevent any other rule from matching. The question is, what rule will match when the parser reaches ”[:” or “Page alias”. Maybe you want to look at Oddmuse:New_Text_Formatting_Rules, but when I reread the page now I have the sinking feeling that I didn’t explain it too well. :(AlexSchroeder

I figured out the answer to my question: PageCluster does not involve HTML parsing. Silly me. – ChrisPurcell

Ok, I do not really get the above yet, anyway. Translations must be as close to each other as possible. There is no doubt that a topic dicussed in different languages is one contents. There is no doubt that having an ongoing discussion in two separated places translated to each other optimizes the overall performance of the involved intelligences. The minimum you have to do is linking original page and translated page to each other. But that’s not enough. I see that the multilingual experiment frightens programmers and carries the disadvantage of a lot of transfered data that pretty likely is not viewed (like if I load a page translated in 5 languages and I rightawy set my filter to read it in one language only - nontheless all data would have to be transferd). Having a bit experimented with rss now it seems more likely to me that an approch of somehow puzzeling together a page you can intantly also see translation to other languge on leads to a result. Mabe somehow with rss and textanchors? Every sentence gets an anchor. The unit is the sentence, not the paragraph. Dunno yet.

Mattis, agree that an ongoing discussion could be interlinked via LocalLink or NearLink… in separated places. I do believe in asymetric conversations. But I strongly disagree on the way of using sentence a a unit. I still think the differents page translation here or elsewhere are just small spokes to build a local LinkLanguage & a first SeedPosting to invite other people to contribute in any language ;-) So ok for the minimum as some LocalLink. But strongly disagree (in the WikiNow) on putting the page-translation via a textanchor solution. I don’t know why : pehraps pages could become very long and complex imho on a technical point of view for the newbie ? Let’s say for the moment i don’t want to produce any TranslationSwizzling as I tried to understand ContextSwizzling and ContentSwizzling.

Define external redirect: FooBar

EditNearLinks: ContentSwizzling SeedPosting EmacsWiki PageClusters ContextSwizzling PrimarilyPublicDomain


The same page elsewhere: