On Wednesday 31 January 2007 12:38:38 Platonides wrote:

Localization is done by volunteers, sometimes with contradictory guidelines.

Hardcoded wikilinks inside message strings to pages not existing in vanilla Mediawiki are a clear DO NOT. This has to be rule number 1 for all translation teams and also has to be a strict rule for every svn-committer who checks in translations for others.

[[{{MediaWiki:grouppage-sysop}}|administrateur]] fixes it.

I' suggest this short syntax which is even used in some places: [[{{int:grouppage-sysop}}|administrateur]]

This solution fixes it for the strings linking to adiministrators. But what about the other hardcoded links in message strings? We would need to introcude some more mediawiki pages that declare these links.

I advocate for this consistent scheme: MediaWiki:$PAGE-url. This gets used already for url definition pages (but not everywhere).

These pages (not existing by default) get referenced hardcoded inside message strings from the MessagesEn.php file (I am not talking about the url pages like those called from mediawiki:sidebar): [[{{ns:project}}:Metadata]] [[{{ns:project}}:Administrators|administrator]] [[{{ns:help}}:Contents|help page]] [[{{ns:project}}:Searching|Searching {{SITENAME}}]] [[{{ns:project}}:Policy]]

Currently there are 151 language files in svn-mediawiki. No let's hope that other languages do not link even more pages. So 151*5 gives you 755 potential non-existant pages you'd need to care about.

Ok let's assume currently it is only one fourth of that number (cause of incomplete files and because of same names of pages in different languages). These would be still around 190 pages you'd need to make redirects in the wiki and whatnot in order to point people in every language always to the right place (or you touch all messages in language you weren't even aware of, that would be "some" more edits).

There are 10 ocurrences of [[Wikipedia:Administrators|administrator]] on [[en:Special:Allmessages]], all of them on customized messages.

The administrators are just one example. As well you didn't really consider the amount of interface languages (see above).

Be aware that when translators start using it and most references have been changed to this geeky code, some server admin will start complaining about slow rendering and undo all/invent a new way. ;)

I hardly can't believe that. I don't see how a {{int:PAGE-url}} could be more confusing than {{ns:project}}:PAGENAME. Quite the contrary.

And I can't really see how a {{ns:project}} can perform better than something using another replacement mechanism.

Arnomane

On Wednesday 31 January 2007 22:23:03 Platonides wrote:

...

I hardly can't believe that. I don't see how a {{int:PAGE-url}} could be more confusing than {{ns:project}}:PAGENAME. Quite the contrary.

And I can't really see how a {{ns:project}} can perform better than something using another replacement mechanism.

It is supposed to be better using [[Project:Foo]] instead of [[{{ns:project}}:Foo]]

Both are cause severe troubles on multilingual wikis as pointed out by me.

By the way the [[{{int:NAME}}|NAME]] thing doesn't work. int: always expands to the page in your interface language and not to the page of the wiki default language which would be needed in that case here.

Arnomane

Hoi, I want to say that this is one of the most helpful threads I have seen in a long time .. Thank you so much, Thanks, GerardM

On 2/1/07, Daniel Arnold arnomane@gmx.de wrote:

On Wednesday 31 January 2007 21:03:49 Daniel Arnold wrote:

...

These pages (not existing by default) get referenced hardcoded inside message strings from the MessagesEn.php file (I am not talking about the url pages like those called from mediawiki:sidebar): [[{{ns:project}}:Metadata]] [[{{ns:project}}:Administrators|administrator]] [[{{ns:help}}:Contents|help page]] [[{{ns:project}}:Searching|Searching {{SITENAME}}]] [[{{ns:project}}:Policy]]

I have now written a small patch that fixes this problem for MessagesEn.php. I used the {{MediaWiki:PAGE}} (thanks Platonides for the idea) syntax as it always points to the page in the default language which is desired in this case here.

If the patch gets applied this change should be applied to all 151 MessageXX.php files as this problem causes currently quite some trouble in multilingual wikis and as the fix can be done in a search and replace manner which doesn't change any real text (and thus you don't need to know the language of the language file you are fixing).

Furthermore I added to the after-installation-mainpage a list of pages not existing in vanilla MediaWiki which interface definition files (in any language) expect to exist though. So after installation of MediaWiki people have a quick overview in one place which pages they need to customize in order to avoid broken links in the interface.

See: http://bugzilla.wikimedia.org/show_bug.cgi?id=8846 for the patchfile against recent SVN version.

Have fun, Arnomane

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 2/2/07, Daniel Arnold arnomane@gmx.de wrote:

...

See: http://bugzilla.wikimedia.org/show_bug.cgi?id=8846 for the patchfile against recent SVN version.

Erm. I now tried quite a while in #mediawiki to get this really really small patch inside Mediawiki main line and I am really astonished by the lack of interest submitting something that harmless like this patch.

I want to proceed fixing all the other 150 files too and: a) I don't want to waste my time whith doing something wrong and then being told about it *after* I did edit all other files. b) I don't want to wait for every single file that long.

Hey I want to improve MediaWiki and I am not someone who asks for getting svn access in order to make MediaWiki capable making coffe or tea.

Folks you wonder why people don't fix the problems by themselves and submit poor bugzilla bug reports?

This is the reason.

I eventually volunteered that I would commit it if you finished it, and that offer still holds. As for the general case, unfortunately, yes, people ignoring patches is a problem, but there's not much that can be done about that in a volunteer project.

Hi,

I now have fixed the internal links in MessagesEn.php and all message files from A to C (except MessagesAr.php which will follow later, blame my text editor's rtl bugs). See http://bugzilla.wikimedia.org/show_bug.cgi?id=8846 for patch files (all applied to SVN) and http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/languages/messages/?s....

Basically I did replace things like "blabla see [[Project:help|help]]" with "blabla see [[{{MediaWiki:helppage}}]]" (among other things like localised namespace names and custom links, see below). See previous mails for the detailed reasons.

However "{{MediaWiki:" is only temporary syntax as in multilingual wikis people would also like to get linked to localised project pages in case they exist. With my current patch this is possible if people customize the messages for that language locally in their wiki. In order to reduce the need for such customization we need a new special template token (maybe called "{{link:") that would need to work the following way (I explain it with the example of MediaWiki:helppage):

Embedd MediaWiki:helppage/your_language -> if not existing in the wiki database: embedd MediaWiki:helppage -> if not existing in the wiki database embedd 'helppage' from MessagesEn.php.

This would cause the following: Certain localised links can be activated by local admins with one single MediaWiki namespace edit individually for each language. This would be probably the best solution between "link hell into nowhere" and "default language only links".

This approach is closely related to the solution idea of another link bug (interface URLs resolution order (splitted from "Major flaws...")):

http://lists.wikimedia.org/pipermail/wikitech-l/2007-January/thread.html#292... http://lists.wikimedia.org/pipermail/wikitech-l/2007-February/029335.html

So far to the reasons of my changes. My fix also means standardisation as the same page links only need to be defined in one place.

Furthermore there is now a narrow set of link defining pages which is allowed to be used in standard system messages (no custom link calls anylonger!):

http://www.mediawiki.org/wiki/Manual:Configuration_settings#Page_customizati...

+ the new "MediaWiki:policy-url" link definition page. See also current MessagesEn.php in SVN.

So my work resulted in these style guidelines for translations:

1) Do not use local namespace names in standard message strings. The same applies for localised wiki markup (like translations of "thumb" and such). Especially something like "Benutzerseite von [[Benutzer:$1|$1]]" (German "user page of ...") instead of "Benutzerseite von [[User:$1|$1]]" is dangerous as the link does not work in wikis with a different name for user namespace (basically all wikis with a default language other than German, canonical namespace links get translated to localised, use {{ns:user}} and such when not using alternative link text or text outside links).

2) Do not link article namespace images or or other local content. Something like "Your [[IP adress]] has been blocked..." is wrong. It has to be "Your IP adress has been blocked...". No other wiki than Wikipedia or a wiki on networking will usually have an article about IP adresses.

3) No Cross-wiki/interwiki links. Especially links like "[[w:en:IP adress]]" are not allowed as well as interwiki link definitions into Wikimedia wikis are removed in default MediaWiki.

4) Do not directly link any project pages in messages. Use only the link definitions such as {{MediaWiki:helppage}}. Do not create new link definitions in your local MessagesXX.php file.

As you probably can imagine, fixing all 151 message files takes quite a while and thatfor I call for your help. As well I wasn't able to fix every link (tagged with '# problem with link' in message files). So please retranslate them now from the English original using the new link guidelines.

I will post a detailed list of affected message strings that need retranslation on mediawiki-i18n-l http://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n in the next hours and hope there for coordination of the remaining message file fixes.

Have fun, Arnomane

On Tuesday 06 February 2007 02:50:47 Simetrical wrote:

I suggest you familiarize yourself with sed. A while back I was trying to do something pretty similar to this. After a couple dozen languages I was ready to go insane and left off for a few months. While it took several hours to figure out how sed worked and run it, it was a hell of a lot quicker than it would've been for me to finish it all by hand.

Of course, your job may be a little trickier, since you'll probably need to run one sed for each specific link that needs replacing, but something along the lines of

sed -R s/('anontalkpagetext'.*)[[([^]]*IP[^]]*)]]/\1\2/ Messages*.php

should be a lot faster than manually replacing same in every file.

It is not that easy. It would work like that provided all messages would be similar to the english one. But they aren't. Many "translated" messages don't have any common content with their english counterpart (and sadly some are also looking to me as if that person never did check the own translation). In most cases the strings contain more links and different links than the english ones. So I have to find out manually by content (via Wikipedia interwiki links for example) where a link is pointing at (which I need to know in order to replace it.

Furthermore there are quite some other problems like article namespace links, interwiki/crosswiki links into Wikipedia, translated namespace names in messages (MessagesCy.php even did have a typo in local namespace name in a message; did the translator really check his work?).

So I fear this is pure handwork. At least if I want to avoid creating even a bigger mess.

That's why I call you all for your help. Together this can be solved ways faster and better and I am sure most of you speak at least one language different than English and there are more than 150 people subscribed to that list...

Arnomane