[Pmwiki-users] multi-language support = pageid

[J. Meijer]

I'm thinking about how to support multiple languages. I'm still defining
what I want.

A two-language capability seems to suffice. Pm or Jr WikiFarms could then
extend a single core language (english) with the native language. It would
also be possible to link language-sections in another way, f.e. the
portuguese may prefer to refer to the spanish instead of the english
sections.

Another idea is to provide a url with the language in it:

  www.my.site/en?page=MySite.Welcome
  www.my.site/de?pagina=Herzlich.Willkommen
  www.my.site/pt?pagina=Bem.Vindo

With a localized version of pmwiki there is no need to load an XLPage, only
a patched pmwiki version, improving performance a significant bit
(multiplied over all pages requested). No modifications to pmwiki are
necessary.
International support would have to be the responsibility of pmwiki
partners, not of Pm himself. With pmwiki installations increasing, this
should be feasible.
Alas, the portuguese translation for example was simply not functional (a
few months ago).

The syntax could be localized too, but only superficially: the syntax would
be translated on the fly to the user-language and back to english when
storing the page. Some users (including me) may prefer to use english
whenever they are editing. But I know from translating a BASIC toy
interpreter that a translated syntax can shock you. The machine comes much
closer it seems.

FWIW and OT, I don't think the PmWiki name should be (too) apparent in the
installation. Sites hosting it should not have to be a banner add for it.
PmWiki will always appear with its a set of pages and maybe webservices.
My viewpoint is that the pmwiki name itself should be banned from the url.

Still, these issues do not touch the core problems of having and managing a
multi-language site.

Basically I am now using group-linking: a group in one language refers to a
group in another (and back). Call it a trail if you will. But in a
two-language environment such links are trivial and allow for at least an
introduction to the group in another language. For even better support
several core pages in a group may have such links.
The wiki would have to be aware of such links, so it can transparently
default to the language of choice.
These links might be called knots, because many equivalent pages come
together. Any user would only see the knot as a two-page linking system.
With pmwiki migrating to include page-id's a knot would correspond to a
page-id, and when that page-id exists in a language-domain, it would be an
equivalent page.

Automatic page-translation could be an option and I think it is available. A
crude but effective translation-engine could also be made in PHP. But a
translation with markup intact is probably too difficult. So it is probably
best to just have a dictionary handy.
In an extreme case all words may have hovertext translating them, the first
time they occur... This actually seems like a workable idea.. I'll patent it
;-

And finally, links should never be allowed to be broken. Page renames should
not matter to the interpage linking system. Even external links might tap
into the page-id to never loose a link. It seems the web is in need of such
a system anyway. Wiki's might just happen to lead the way of what will soon
become standard feature. Not Microsoft but personal micro wiki's that link
among themselves.
All wikis should standardize on a page-id issue mechanism which trades a url
for a pageid. When a normal url is given to a wiki, the wiki contacts the
remote site for a pageid. Suggestion:
    <pageurl>&metadata=pageid
So
    <wikiurl>?pageid=<pageid>
is equivalent to issueing <pageurl>, but the user would get the page in his
own language. Seems like a great idea to me.

The web will be a world-wide wiki.
Pmw2 will be a great show.

Lets keep the engine low-fat, small and effective.

-jm