Support

Problems? Questions? Suggestions? Write your message below. – See also the FAQ or try to catch us in IRC.

Your request has been forgotten? Feel free to post a reply to bump the thread to the top. The thread summarization feature is broken, see Phab:T245109. Very old threads have been archived.

CLOSED This issue is closed by Siebrand

I think will be good idea to refer to Donate button with int: of button text message.

 Done

CLOSED This issue is closed by Siebrand

Screenshot of Special:ImportTranslations of 2009-11-18

I've used Special:ImportTranslations several times today, and found it working pretty well for me. Seing it working inspired me to reword few of my translated messages. I've got some minor suggestions of improvements, found one drawback, and there is one is one oddity.

• In MediaWiki:Translate-manage-import-diff, I'd suggest to use {{int:pipe-separator}} instead of |
• Also in MediaWiki:Translate-manage-import-diff, I'd suggest to convert $1, the message name, to a link. Benefit: When you detect errors, or want to make enhancement, you can open a background window instantly, which you reload when the import is done, so as to make the desired adaptions.
• When messages are fuzzied in the imported file, the fuzzy flags are correctly imported. I was expecting the default action to be "import and fuzzy" for those messages, but that was not so. If there are no objectons, I'd look into changing the code so as to make that so.

Drawback:

• The 10 second import time limit is too small, it boils down to ~20 messages. That is few.

Odd:

• I found two messages being new, which imho should not be - see attached screen shot showing one of them. I tried several reimports of the (unaltered) file. Each time, I was told, they were new.

• The two changes messages most probably have a trailing space in the translation, and are imported without a trailing space.
• timeout issue is known
• will look at the other things you mentioned later.
• if "fuzzy" is in the imported message, the message is properly imported as fuzzy. So no need to change anything there. "Import and fuzzy" is meant for the source language, and then fuzzying the derivatives. Importing 'ksh' should never lead to fuzzying other translations.

Thanks for the feedback!

Import and fuzzy is different from import and fuzzy all translations. The first can be used to force fuzzy, for example for merge conflicts.

Ok, fuzzying understood. I won't select it. Probably that should be explained on the import page, or an associated help page. Maybe suppress the choice, if import language ≠ source language of the group?

CLOSED This issue is closed by siebrand

I need to change the name of my language, "Romagnolo". See this page: http://translatewiki.net/wiki/Portal:Rgn. I'm sorry, but I wrote it in Italian. The language itself is named Rumagnôl, with special accent on "o". How can I have it written this way? Thank you very much!

Wikipedia gives "Rumagnòl" as autonym. Is the language having trouble making up its mind on how to write the name? (you can indeed read irony in this, and it is meant to be read as such - it is very annoying to us if we quickly support a language that has little to no presence on the internet, but apparently there are a lot of things to sort out regarding the language. I think this may in the short term lead to us only supporting languages if they are also supported in CLDR...)

Please clarify why you and Wikipedia name differing autonyms.

Fixed. Wikipedia's version was not correct.
And now?

 Done mwr:59227

I do not think that presence in CLDR is currently a good criterion for supporting a language here. It may take many months or more than a year to have a language added to CLDR. :-( Then you can start to get its basic data right, which again may take months, since CLDR most of the time does not accept new or corrected data :-(

The CLDR is like the ISO-639-3 a fine standard that is essential for the language policy. The CLDR would fit in perfectly because it provides a service that would benefit translatewiki.net From my perspective it would suffice for the information to be supplied to the CLDR as it does provide the information and as it signals the relevance and importance of providing this infrormation. Accepting corrected data should take more time, correcting in standards is highly disruptive. Thanks,

Annoying bug in memcached throws errors to users. We are looking for a fix, but haven't solved it yet.

When accessing User:Homo logos page, I always get an error:

MediaWiki internal error.

Original exception: exception 'MWException' with message 'Wrong sidebar here!<br />
/wiki/User:Homo_logos' in /var/www/w/includes/Skin.php:2052
Stack trace:
#0 /var/www/w/includes/SkinTemplate.php(483): Skin->buildSidebar()
#1 /var/www/w/includes/OutputPage.php(1268): SkinTemplate->outputPage(Object(OutputPage))
#2 /var/www/w/includes/Wiki.php(382): OutputPage->output()
#3 /var/www/w/index.php(123): MediaWiki->finalCleanup(Array, Object(OutputPage))
#4 {main}

Exception caught inside exception handler: exception 'MWException' with message 'Wrong sidebar here!<br />
/wiki/User:Homo_logos' in /var/www/w/includes/Skin.php:2052
Stack trace:
#0 /var/www/w/includes/SkinTemplate.php(483): Skin->buildSidebar()
#1 /var/www/w/includes/OutputPage.php(1268): SkinTemplate->outputPage(Object(OutputPage))
#2 /var/www/w/includes/Exception.php(167): OutputPage->output()
#3 /var/www/w/includes/Exception.php(194): MWException->reportHTML()
#4 /var/www/w/includes/Exception.php(292): MWException->report()
#5 /var/www/w/includes/Exception.php(351): wfReportException(Object(MWException))
#6 [internal function]: wfExceptionHandler(Object(MWException))
#7 {main}

Purged the page cache directly by editing the URL (?action=purge). It's working now. Thanks.

This is an issue that we have been investigating for the past few weeks with our caching server. Normally you do not get this exception, but you would get an incomplete sidebar. While we are investigating this, we know that about 50 page views will get this error every day; without it, we would not be able to solve it.

I've got one of those today, too. I reloaded the page immediately, and got a good copy.

CLOSED This issue is closed by siebrand

StatusNet is no longer supported.

The "Invite" StatusNet message is used in two different context: as a tab title and as a link.

Two messages need to be created.

"Login" also has the same problem, except that it's used in three different contexts (as title, tab and upper link). In Arabic the tab and the title will be translated nouns, but the link will be a verb.

This is one of the gigantic drawbacks of using gettext l10n extracted from source files. Without changing the text (that is hard coded in the code), this *cannot* be done. I'll point Brion here and will ask him what his thoughts are regarding this issue.

And with Gettext it is common that one string is used in many places, if the developers don't use the context parameter often.

You mention using a "context" parameter. Is that something that can be used to separate "message text" from "message text" in the code? This would be very, very, helpful to distinguish verbs from nouns, for example. Please provide an example on how to use this; can forward that to the StatusNet devs.

Ok, I've hacked in support for this, not yet used.

pgettext and npgettext are implemented as macros (wtf?!) in gettext.h and aren't provided in PHP's gettext module, but it was easy to add compatible wrappers and I've confirmed they actually seem to work. :)

Warning: xgettext by default doesn't recognize those as keywords for PHP source files, so these parameters must be added to the xgettext command-line when rebuilding the .po template:

   --keyword="pgettext:1c,2"
   --keyword="npgettext:1c,2,3"

Something like this, if consistently used, should do the trick: pgettext("tab", "Login") vs pgettext("button", "Login")

Anything else we should add to the list before we go contextualizing a bunch of messages?

CLOSED This issue is closed

Should refer to ZIP code.

 Done mwr:59207

CLOSED This issue is closed

Should refer to postal code as Payflowpro gateway-donor-postal.

 Done mwr:59206

CLOSED This issue is closed

Should refer to American Express not Amex. Will be good idea to make replacement in other messages.

 Done mwr:59206

Iltever has used the kr (Kanuri) code in stead of the krc code.. Can this be fixed ? Thanks,

Yes, you move the pages without leaving a redirect behind.

P.s. this does not happen if users actually use the language they translate to as their user interface language!!!

What is MediaWiki:Wikilog being used for?

Special page name

The message fogg-videoBitrate-help appears not making any sense to me, so i made a translation without sense. What doess the original mean?

It is an explanation of what the term "video bitrate" means (i.e. the speed of video encoding in kilobits per second).

Thank you. I first thought, I had understood now. but actually, it does not help me enough to translate the message. Here are my difficulties. We cannot unspecifically chain word like the English or Americans do. Thus "video bitrate" has to become something like "The bitrate of the? a? this? video" - now you say it is being explained, but the original sentence say "sets" not "is" - translated, that is a huge difference. Now again "the encoding bitrate for video" has to become "the bitrate of the encoding of a? the? this? videostream" and my final sentence: "The bitrate of the? a? this? video is? sets? the bitrate of the encoding of a? the? this? videostream, and is measured in kilobits per second." does not look like making sense, does it? What I maybe could extract is: "The bitrate of the encoding of videostreams (in general) is measured in kilobits per second here." Is that what is meant?

Yes, I often run into the same ambiguity problems that you mention, but this specific English message is particularly badly written. Perhaps someone should rewrite it (Siebrand?).

Anyway, the message name is "videoBitrate-help", so surely it should be an explanation of what it generally is. What I translated is: "'bitrate' means the encoding speed of the video (in kb/s)."

Please suggest alternative text. Busy today until I get to my hotel room later today.

Two ideas:

• The term 'bitrate' means the encoding speed of the video (in kb/s).
• The bitrate is the amount of data output produced by encoding the video, in kilobits per second.

In MediaWiki:maps error parameters, the last word, "syntaxis", is likely to be erroneous. Either some kind of axis, or the singulare tantum word "syntax" are likely being meant.

 Done

The word maps overlays can be translated in several ways. Is there a clue, as to which kind of an overlay might be meant?

Maybe check the code?

I believe, maps error parameters should have PLURAL support, since the number of messages following it may likely vary.

Then add it.

The message lqt-talkpage-history-tab is translated in various (imho incompatible) ways. Does it refer to a headline, a subject line, a page title, of a header (such as in e-mail, or html pages, e.g.)?

Could you please look it up in the code and document it? ktnx.

This message uses PLURAL for one verb declension but not for the subject and the first verb, which can lead to an ungrammatical result.

 Done mwr:59043