Difference between revisions of "Support"

From translatewiki.net
Jump to navigation Jump to search
Line 460: Line 460:
 
Where can we configure the texts "string", "interger", or "boolean" being inserted in {{msg-mw|Configure-ext-settings-dep-error}}, according to the description? I expect them to need to have grammatical gender dependent articles added, but I could not find such texts in the messages of this extension. --[[User:Purodha|Purodha Blissenbach]] 15:59, 25 March 2009 (UTC)
 
Where can we configure the texts "string", "interger", or "boolean" being inserted in {{msg-mw|Configure-ext-settings-dep-error}}, according to the description? I expect them to need to have grammatical gender dependent articles added, but I could not find such texts in the messages of this extension. --[[User:Purodha|Purodha Blissenbach]] 15:59, 25 March 2009 (UTC)
 
:Create a bugzilla. No idea what you want here. It is a very technical message targeted at the more tech savvy. [[User_talk:Siebrand|Siebrand]] 16:24, 29 March 2009 (UTC)
 
:Create a bugzilla. No idea what you want here. It is a very technical message targeted at the more tech savvy. [[User_talk:Siebrand|Siebrand]] 16:24, 29 March 2009 (UTC)
  +
:My understanding is that "string", "integer" or "boolean" is not the literal text to be inserted, but just the type of data that will be inserted. – [[User:McDutchie|McDutchie]] 16:58, 1 April 2009 (UTC)
   
 
== Gender support needed ==
 
== Gender support needed ==

Revision as of 16:58, 1 April 2009

translatewiki.net
Introduction
Getting started
Translation tutorial
How to start
See also
Localisation guidelines
Translating offline
FAQ
Support

Problems using translatewiki.net? Don't know what to do? Have a feature request? Write your question below. Please link to a particular message if your question is about it.

Wrong text on Special:Movepage

(mentioned in bugzilla:15114) Message which is displayed on Special:Movepage implies that page will not be moved if the target page exists, while it's not true. This message should be rephrased or be permission-dependent — VasilievVV 00:08, 30 December 2008 (UTC)

Any suggestions? This isn't exactly the stuff we do. – Nike 13:36, 13 March 2009 (UTC)

What does this message mean?

This section is a place to request for the explanation about the usage of the messages. If you want to know where and when a specific message is used, put that message here.
  • Coll-savedbook template ("saved_book")
    • requester: Ans 09:37, 12 March 2009 (UTC)
      I will ask from Johannes when he comes back. – Nike 15:21, 13 March 2009 (UTC)

Abusefilter-edit-throttle-groups

Without explanation or use case, I have problems to translate Abusefilter-edit-throttle-groups ("Group throttle by:"), the original:

Group throttle by:

(one per line, combine with commas)

My questions: Is there an input field inserted behind the 1st colon in the message? "Throttle" is singular, but grouping requires at least two items to be useful, is that an error or am I missing something? What kind of info is to be put on separate lines, throttles, or groups? Where do their names or other identifiers come from, i.e. how would a user know them? How can one combine things with commas, when they have to be on separate lines? --Purodha Blissenbach 07:34, 9 March 2009 (UTC)

It's the label for a textbox on the right. The throttles are somewhat complicated, and described (probably poorly) at MediaWiki.org. Werdna 01:22, 27 March 2009 (UTC)

Abusefilter-edit-builder-vars-diff

Translating messages in the Abuse Filter extension is quite some guesswork, since explanations are missing. I neither could find a wiki where I could inspect messages in their context, nor could I get it to work in my test wiki.

Abusefilter-edit-builder-vars-diff ("Unified diff of changes made by edit") (Unified diff of changes made by edit) is hardly making any sense to me, and I believe also not to the average English reader. Btw. "diff" is highly technical jargon, and likely not generally understood well enough. That the message is hardly understood shows its German translation as Vereinigter Versionsunterschied der Bearbeitung, which is grammatically self-contradicting, re-translated: "The difference of a version of editing combined (or merged)" (Combined with what? Combining needs at least two, yet there is only one here. :=) --Purodha Blissenbach 08:26, 17 March 2009 (UTC)

"Unified diff" is a specific format, see wikipedia:diff#Unified_format. – Werdna 09:36, 17 March 2009 (UTC)

Oh, I see, thank you. So I could leave "unified diff" untranslated, and the message boils down to:
Show differences in ''<span lang="en">unified diff</span>'' format
(as "the change" and "the edit" translate the same, they cannot be used here without creating utter confusion) Good! --Purodha Blissenbach 13:11, 18 March 2009 (UTC)

Suggestion to improve original English message

If you have any suggestions to improve the original English message, put them here
  • Restoreprefs ("Restore all default settings (in all sections)")
    • current message: Restore all default settings
    • suggested message: Restore all default settings and save
    • note: to inform the user that, it will be saved immediately (without prompt), and can't be undone. --Ans 08:43, 3 March 2009 (UTC)
    Wouldn't adding prompt to be more suitable in this case? – Nike 15:03, 13 March 2009 (UTC)
    Adding prompt is more suitable. However, this is just interim solution, while the prompt hasn't yet been implemented --Ans 15:15, 16 March 2009 (UTC)
    Not changing. The proper solution should be the prompt. Siebrand 01:13, 27 March 2009 (UTC)
  • Configure-setting-wgSummarySpamRegex ("Spam filter regular expressions for edit summaries")

Call-text

Should use {{#special:}}, because the special page name is shown als plain text. (See Support/Archive/2009/2#Exporttext for more information) --Der Umherirrende 13:13, 21 February 2009 (UTC)

I wanted to make the change to the English version of the message, but I am a bit unhappy when I see the result at translatewiki.net. I assume, we shall get a lot of unhappy questions from translators. You even do not see when you mistype the special page name :-( Any ideas to make that better?
Btw. (disregarding the abovementioned problem) can we keep that as a general rule: When a special page name is mentioned in the text, or has a wikilink to it, not having an anchor text (i.e. a wikilink without "|" inside), then use {{#special:}} even if the English original does not? --Purodha Blissenbach 01:10, 22 February 2009 (UTC)
No. Translations should stick to the source text. If the source text has an i18n issue, that should be addressed. Siebrand 10:39, 23 February 2009 (UTC)
Ok, that would mean to amend the original in such cases (even if that was technically unnecessary for English alone).
That leaves us with the problem of error messages in cases of extensions not installed in translatewiki.net. Do you see an easy way to collect the names of their respective special pages from extensions? Having a list in translatewiki.net, against which special page links could be checked? We should avoid {{#special:… rendering "Special:Hammernit!" unnecessarily. Worst, this would hide typing errors in special page names in our translations. --Purodha Blissenbach 19:13, 23 February 2009 (UTC)
I'm working on a script to grep special page names from extension source files, and adding an "Extension $1 not installed" special page as an alias for each of those, making them known to {{#specialPurodha Blissenbach
There is probably an easier way, because the Special:AdvancedTranslate already can load all the aliases. – Nike 15:05, 13 March 2009 (UTC)
Yes, there is, I've seen that. I'm working on it. --Purodha Blissenbach 09:12, 17 March 2009 (UTC)

Modifications to FreeCol source language [en]

I was told to post here a patch for review on updates to the English for Freecol. Nickshanks 17:06, 21 February 2009 (UTC)

Nike needs to handle this. Siebrand 19:13, 24 February 2009 (UTC)
Applied as is. The following messages needs updating due to added ellipsis: menuBar.game.open menuBar.game.save menuBar.game.preferences menuBar.game.selectLanguage menuBar.game.declareIndependence menuBar.game.quit menuBar.game.retire menuBar.game.highScores menuBar.view.europe menuBar.view.tradeRoutes menuBar.view.findColonyNike 14:01, 13 March 2009 (UTC)

Original English messages a bit unclear/too technical

I don't think the average user knows what a namespace is (i.e. non-technical users).

So I think a few messages in English should be changed.

  • Powersearch-ns (used on Special:Search)
    Current message: Search in namespaces:
    Since it's not necessary and most people wouldn't understand the "namespaces" part i suggest we change it to "Search in:"
    Other messages that include the word "namespace" aren't as visible, and the message is rather unclear if you remove it.
  • Blanknamespace (used on e.g. RC, Search)
    Current message: (Main)
    This is fairly hard to get a global name for the main namespace that's better - e.g. for Wikipedia it could be "Article", but for Wiktionary it would be "Entry" and for other sites it could vary a lot. So perhaps "Main" is the best we can do?
    It is not at all clear what the parentheses mean (my friend who looked at it thought that the main namespace was selected or something). If we want to tell users the namespace doesn't have a prefix - shouldn't that be explicit: "Main (no prefix)"? Either that or removing the parentheses all together: "Main". I think the former would be better.

Does this sound like good ideas? What do you think? Skalman 17:39, 26 February 2009 (UTC)

During my first encounters with MediaWiki, I had these problems, and I did not understand namespaces for a while, and few related things. That was years ago, and I got used to them. --Purodha Blissenbach 11:55, 28 February 2009 (UTC)
Yeah - we can't presume that readers will even want to understand such stuff - as a reader you shouldn't have to encounter the word "namespace", while it is quite useful for editors. Skalman 15:08, 2 March 2009 (UTC)
I agree that "Search in:" is probably enough for the first message. If a reader doesn't understand the choices that are in the tickboxes after that then that reader probably won't understand "namespace" either! I suppose an alternative would be to make "namespace" into a link to a help page on Meta that would explain what a namespace is. I also support your suggestion "Main (no prefix)", although again for general readers who don't know about prefixes this might be just as confusing as before. Lloffiwr 19:01, 7 March 2009 (UTC)

Globalblocking-logentry-expiry ("expiration $1")

What is $1 in Globalblocking-logentry-expiry ("expiration $1")? If it is a duration, fine. For a date and time of expiry, we preferrably had date and time separated for a better translation. --Purodha Blissenbach 10:37, 5 March 2009 (UTC)

Actually, this is one of the rare cases where we can do without a date/time split in a text message, the reason being its terseness. Should we generally have date/time separated everywhere, except in tabular list enties, or should we be more lenient? I lean towards the more rigid version, among other reasons because I assume that, sooner or later, there will be more languages that need a separation, or benefit from it. --Purodha Blissenbach 23:38, 5 March 2009 (UTC)

It is wfTimestamp( TS_ISO_8601, $block->gb_expiry ) or 'infinity', and could be manipulated before being added to the log entry. Siebrand 09:38, 6 March 2009 (UTC)

MediaWiki:Centralauth-merge-no-accounts

Centralauth-merge-no-accounts ("No accounts matching your name were found in the central account tracking table! The database must be corrupt.") tells the user that his username wasn't found in the database and that the database is corrupted. Shouldn't there be some advice to the user about what to do or what that means to him? --::Slomox:: >< 16:59, 9 March 2009 (UTC)

Imho, Yes. How about: "You cannot proceed at the moment, and please inform an [[Special:Listadmins|administrator]]."
I do not think that wiki administrators actually can do anything for the problem. Currently Wikimedia is the only user of Central Auth, and bugs should be filed to their bugzilla. – Nike 14:33, 13 March 2009 (UTC)
Yeah, I was a bit short-sighted. How about: "You cannot proceed at the moment. Please file a bug at [[:bugzilla:|MediaZilla]] selecting the product "Wikimedia", and the component "General/Unknown", so as to help getting the issue solved as soon as possible. Thank you."
Well yeah, but that has the other problem of hard coding Wikimedia. – Nike 17:30, 18 March 2009 (UTC)

Messages

I have a problem with messages:

please change this to:

The message MediaWiki:revdelete-uname/pl while needed is added in software to the messages MediaWiki:revdelete-hid/pl and MediaWiki:revdelete-unhid/pl. In Polish it is:

Sign "+" was used only as separator. It is impossible to correctly translate this messages now. Sp5uhe 22:43, 6 February 2009 (UTC)

So basically you want to combine five messages into six message (un)hid × (uname|summary|content) matrix? Seems very reasonable to me. --Nike 08:53, 20 February 2009 (UTC)
Any takers? Siebrand 12:19, 21 February 2009 (UTC)

Linking MediaWiki manual from qqq pages

Hello. I just thought it may be helpful if the qqq messages automatically include a link to mw:Manual:Interface/{{BASEPAGENAME}}. If it's too much of mess, please just ignore it. --Aotake 23:36, 8 February 2009 (UTC)

If I had understood what links exactly where you are talking about, I might do something. If I try out, what you suggest, on some arbitrary …/qqq pages, I get links to nonexisting pages, such as http://www.mediawiki.org/wiki/Manual:Interface/Red-link-title. --Purodha Blissenbach 02:07, 9 February 2009 (UTC)
For the "Configure Settings" group, there is almost always a similary named page at the MediaWiki wiki with more information about the function. For example: Configure-setting-wgRedirectSources ("Regular expression to restrict URLs which will be displayed as 'redirected from' links") and mw:Manual:$wgRedirectSources. --Boivie 07:24, 9 February 2009 (UTC)
Ok. That is not accessible via a reference, made as simple as using {{BASEPAGENAME}}, but still, there may be a way to do it. To me it looks like the information in the /qqq space and that in the mw:Manual:… pages overlap, or even are, or should be, identical? If that is true, we should likely have only one place where they are kept, in order to not duplicate efforts, and improve on their quality, do we? If I am right, the MediaWiki Wiki seems to me the more logical choice for them to live in, especially since there exists an established mechanism there of having them in multiple languages (I am not saying a good one!), which /qqq alone does not offer.
On the other hand, ony could say, basic documentation should usually be part of the program code, thus /qqq, which then gets exported into various places including the MediaWiki manual, where it can be translated but (the original English version) not altered.
--Purodha Blissenbach 09:02, 9 February 2009 (UTC)
I agree that having only one place to keep information is better. It would be great if there is a way to transclude the MediaWiki manual into betawiki translating pages. . . By the way, I did not realize the possibility of using MessagesQqq.php as a way to provide the information on each system message. It would be useful if one could display mediawiki:messageid/qqq in editing page of each mediawiki pages, and I assume that could be realized by transcluding it in mediawiki:protectedinterface, but it seems that /qqq is not imported into MediaWiki namespaces of Wikimedia projects. Do you happen to know why? --Aotake 12:08, 9 February 2009 (UTC)
MediaWiki indeed seems to block access to messagesQqq Usually, language code qqq is not included in Names.php and thus not relectable. If it is, however, like in Betawiki, strange things may happen such as bug 17445. Nevertheless, also the MediaWiki wiki could or should provide access to the /qqq Namespace for the abovementioned reason. Maybe, we can make that a clean (de)selectable option. --Purodha Blissenbach 09:10, 11 February 2009 (UTC)

I don’t know anything about the technical side of the original question in this discussion. But I am interested in the general topic of how to get the information we need in order to translate properly. I think it would be useful to get the developer who writes a message or extension to provide documentation on each message as part of the process of writing the new messages into the mediawiki sourcecode. It is suggested above that this documentation already exists, so that it should already be possible to extract that information and link it automatically to translate.net. But is the documentation available now written in plain English that non-software engineers can understand? If not, then I am not certain that it will be helpful to have this information included on translate.net at all – in fact it might discourage translators such as myself completely!

With regard to linking information on the /qqq pages with information on Mediawiki, an idea which I support, I am not clear from the discussion above, whether we will still be able to add more information to the /qqq pages. I am thinking in particular of the sort of information which a developer might not know, especially hints to translators on grammar and vocabulary, for example: synonyms, the grammatical context of a word (mainly whether it is a noun or a verb).

At the risk of stating the obvious, the type of information which we have on our /qqq pages at the moment, includes any of the following, where relevant to the message:

  1. What pages use the message
  2. What actions use the message or under what circumstances the message appears.
  3. Notes on user rights which you must have in order to see and use a message, which is not seen or used by all users
  4. Where the message appears (button label, page title, text, etc)
  5. A description of each variable in the message, with links to variables which are other messages
  6. If the message is a variable in other messages then links to those other messages.
  7. The name of the extension to which it belongs, linked to the description page of the extension on Mediawiki or translatewiki.net.
  8. Links to examples of the message in action, either on translatewiki.net or as screenshots.
  9. A link to other messages with the same wording
  10. Translation hints such as synonyms for terms, the grammatical function of a short message, either a phrase or one word (mainly whether a noun or a verb).

If it is possible to get a formal structure for developers to create documentation as they are adding messages to Mediawiki, then the first 6 items are (where relevant) the bits of information needed to be recorded by the developer. Lloffiwr 11:11, 21 February 2009 (UTC)

Nice idea, but it will fail. Most of the time developers are not interested in localisation, or more precisely, not even aware of the requirements for localisation. Often they are willing to make i18n related changes to their software to facilitate proper L10n. Going beyond that is wishful thinking, I think. Asking them about specifics on an IRC channel will work, but most of the time it will be RTFS to find out what a message is used for. 'We' translators have to care for our own, and the more technically able people should be as involved as possible in making the life of less technically able translators easier. Us staff members are committing to that, and we hope that our core team will keep on growing. Siebrand 11:45, 21 February 2009 (UTC)

There are various guides there for new developers, none of which is really good, and even together they are far from comprehensive. Yet, as time passes by, we should let pointers to and hints about adding qqq content sift into them ;-) including the above numbered points. Being a developer, I know that one often simply has no way to know, or even guess, what questions translaters will ask about certain pieces of text. Being a translator, too, and especially being in contact with translator to some other languages, I know that we even hardly have a chance to know what our fellow translators might need to know so as to find good translations. We only can keep going to collect, in best wiki manner, all relevant informations in the qqq pages.

Ideally, the related MediaWiki Wiki manual pages and our qqq pages should be linked to each other, and I bet, we'll find a way to make that happen. --Purodha Blissenbach 00:38, 22 February 2009 (UTC)

Trick wanted: addressing localized namespace names.

Wikis may have their own preferences about how they call certain namespaces. I found especially Template: prone to have an array of possible translatons that may, or may not, fit individual Wikis style of using templates. If I want to spare installations the need to alter translations, when they choose a namespacename different from my translation, I could use e.g. {{ns:template}} in my translation. While this is fine in the most usual use case — the local installations namespacename is shown, and it fits the wiki language — it is less than optimal for foreigners using a wiki having a wiki language different from my localization. Say, the wiki languge was English, and the user has set his preferred language not be english, he will see my translation of a message, but now {{ns:category}} in the message will yield "Category" in the wiki language, i.e. not translated properly.

What was rather needed here was a translation in the language, and variant, of the user. How to put these two requirements together? --Purodha Blissenbach 11:06, 9 February 2009 (UTC)

Namespaces are kinda tricky. I'd say the time for this issue is not yet, but later in the future. – Nike 15:08, 13 March 2009 (UTC)

GENDER support needed (if not already there)

lucene search

Can this web install Lucene search extension as in wikipedia? This will enable some language, for example Thai, to be searchable. --Ans 04:51, 26 February 2009 (UTC)

We do not have the functional or technical resources to make this possible. This request will not be granted. Siebrand 13:57, 26 February 2009 (UTC)
I do not understand the request. I thought the default search engine is pretty good now. Is there some problem with it? – Nike 18:31, 26 February 2009 (UTC)
I have several times experienced that a search for some Danish text what I saw used here in the translatewiki either failed, or gave too many hits because of similar use in other languages. I suggest downloading po-files from Translating:Offline and using them to search locally. That way you can use any search tool you like, and no other languages will disturb the search. Byrial 11:38, 27 February 2009 (UTC)
There's no word segmentation in Thai sentences, so mw search can't search Thai words in Thai sentences. However, Lucene 2.1 does segment Thai words, so Thai words can be searched in Lucene 2.1 --Ans 04:59, 2 March 2009 (UTC)
Apart from Thai word segmentation problem, I still cannot search for many segmented phrase, for example, the phrase "ระบุส่วนต่างเวลา" in MediaWiki:Timezoneuseoffset/th is not searchable. --Ans 09:13, 3 March 2009 (UTC)
Lame alternative, but can you use Google? Siebrand 00:18, 6 March 2009 (UTC)
I've just tried google (query for "ระบุส่วนต่างเวลา site:translatewiki.net"). It found this Support page, but not MediaWiki:Timezoneuseoffset/th --Ans 06:33, 9 March 2009 (UTC)
I do no think setting up lucene would be that hard, but is there any documentation for it? I do not have time to just play around with it. – Nike 15:01, 13 March 2009 (UTC)
  1. lucene-search 2.1 doc
  2. lucene-search 2.0 doc
It is a bit complicate, if you want to also setup the incremental updater for the search index. --Ans 14:56, 16 March 2009 (UTC)
Hmm, I've just tried querying google for "ระบุส่วนต่างเวลา site:translatewiki.net", again. It now found the message page MediaWiki:Timezoneuseoffset/th. May be lucene-search extension is not needed now (but nice to have) :) --Ans 15:04, 16 March 2009 (UTC)

Adding language code to edit screen

This is a copy of part of a discussion which has gone to the archive, resurrected because I think that Nike is still waiting for our opinion on which solution is best. Lloffiwr 15:19, 28 February 2009 (UTC)

While most usually translating to ksh, I happen to translate, or rather correct obvious errors, in some other languages occasionally. Several times already I forgot to switch back, and accidentally saved my ksh translations in the wrong language. I'd like some more obvious visible hints - e.g. a different background color of edit fields other than in my default language, and/or a big fat langguage code next to the edit window, or something. --Purodha Blissenbach 23:32, 17 February 2009 (UTC)
Having the language code written somewhere obvious (added to the Save button perhaps?) would be great. If the link from each language portal to the translation tool went to the corresponding language, I think I would use it, and hope to get used to it:-) Lloffiwr 09:09, 18 February 2009 (UTC)
Tried to implement this a test last night. Found it less easy than expected. Though translatewiki.nets edit page of translateable messages is special, it seems to use MediaWikis normal edit fields and buttons. Altering the "Save" button appears not trivial. Postponed. --Purodha Blissenbach 10:23, 22 February 2009 (UTC)
There are places where extensions can add code. Any opinions which baa1-baa6 would be the best at example page ? --Nike 13:14, 22 February 2009 (UTC)
How about baa4, or baa3, or both? Lloffiwr 23:04, 22 February 2009 (UTC)

When trying to find the right place to do it, and, say the users default language was und, when editing a zxx message, I was planning for either of these:

  1. Summary:: [_________________________]
    [_] This is a minor edit [_] Watch
    [Save page to zxx] [Preview] [Show changes] Cancel | [help] (opens in new window)
  2. Summary:: [_________________________]
    [_] This is a minor edit [_] Watch
    [Switch back to language und] [Save page] [Preview] [Show changes] Cancel | [help] (opens in new window)

When editing messages in the users default language, and when editing any other wiki page, nothing should be different from the current page:

  1. Summary:: [_________________________]
    [_] This is a minor edit [_] Watch
    [Save page] [Preview] [Show changes] Cancel | [help] (opens in new window)

--Purodha Blissenbach 17:48, 28 February 2009 (UTC)

Why not combine 7. and 6., and put the additional button of 7. behind the others, and label them 'Save to xxx', and 'Back to zzz' only? --93.131.49.146 07:21, 1 March 2009 (UTC)
Like so:
  1. Summary:: [_________________________]
    [_] This is a minor edit [_] Watch
    [Save to zxx] [Preview] [Show changes] [Switch to und] | Cancel | [help] (opens in new window)
? --Femina 12:33, 1 March 2009 (UTC)
If pushed I would say that I prefer solution number 6 - it is straightforward and not too different from other wikis. If the language code only appears when not in the default language that is fine, but I think that having the language code appear for all languages including the default language code would also work well. However, all of the suggestions made by both Purodha and Nike would be an improvement. So whichever is the option that is most efficient for the site is the option that I support:) Lloffiwr 09:38, 8 March 2009 (UTC)
I for one would like the language only to appear when changed from standard because I am afraid, else buttons may sometimes appear too similar (depending on languages). Also, I'd really appreciate an easy way to go back to my standard language other than having to fiddle with the URL in my browsers address field. This involves scrolling the field sidewards several times, and finding the language code in the middle somewhere, which is really time consuming.
A button to go back is kind of unneccessary, technically, a normal link would suffice of course. The reason why I made it a button in the examples above was mainly the more distinctive appearance of the whole, so as to more likely avoid erroneous clicking. --Purodha Blissenbach 09:09, 9 March 2009 (UTC)
I don't really have any strong feelings about which particular option is best; I'm sure I'll appreciate using whichever option is decided upon:-) Lloffiwr 14:13, 10 March 2009 (UTC)

I see, we have a mild variant "Save (Message Documentation)" now. Thank you. Did you think, that other languages should better not be shown? --Purodha Blissenbach 12:37, 18 March 2009 (UTC)

Qqq is what is causing most troubles, so it naturally needs to be different. What comes to other languages, they are less often accidentally used, and I myself currently and some others may prefer using interface language other than what they are translating. In this case it would always be shown, which is not good. Also, Siebrand didn't really think this is important thing, so I kept the effect on minimal on that basis too. – Nike 17:19, 18 March 2009 (UTC)

Broken feature?

In my watchlist, the feature that highlights pages modified since the last visit seems to have broken recently. It will highlight every pages only a short while after I have checked the last changes. --fryed-peach 03:08, 4 March 2009 (UTC)

This sounds more like a MediaWiki bug than what we have caused. – Nike 06:48, 4 March 2009 (UTC)
Does the problem persists? – Nike 14:58, 13 March 2009 (UTC)
Yes. --fryed-peach 09:25, 16 March 2009 (UTC)

Request for namespace alias creation

Hi, I just renamed ns:Talk for French from Discuter to Discussion. We now need an alias from the old title to the new one. Thanks in advance. PieRRoMaN 14:17, 8 March 2009 (UTC)

When namespace names are changed, a developer *will add* those aliases (or get spanked). Siebrand 15:54, 8 March 2009 (UTC)
Does it mean we don't need to care if links would be broken due to changing namespace aliases? Japanese translators are considering such changes and a request to developers. BTW, it would be great if we could specify multiple aliases for a single namespace in Special:Magic. --fryed-peach 07:58, 16 March 2009 (UTC)
In a way yes, but in a way it forces the translators to make the decision and not to add unnecessary aliases. – Nike 17:16, 18 March 2009 (UTC)

Language variable in messages of Babel extension

There is a variable "$3" in the Babel messages which represents the respective language. The issue is that we are use adverbial forms of the language name in Upper Sorbian (hornjoserbsce) and Lower Sorbian (dolnoserbski). But, the Babel messages require a noun form which has to be declined, e.g:

This user has basic knowledge of $3.
Tutón wužiwar ma zakładne znajomosće $3. (in Upper Sorbian)

At present this results in:
Tutón wužiwar ma zakładne znajomosće hornjoserbsce.

But it should be:
Tutón wužiwar ma zakładne znajomosće hornjoserbšćiny.

Hornjoserbšćina is the actual name of the language, here in its genitive form.

Similar in Lower Sorbian: the adverb is dolnoserbski in Lower Sorbian, and the noun is dolnoserbšćina, genitive is dolnoserbšćiny.

Using a variable here isn't good. I think if you will keep using a variable the two language names should be changed to hornjoserbšćina and dolnoserbšćina in names.php to use the variable later on with the GRAMMAR template to express the respective grammatical case. But, I don't know if there will be any complications with the hitherto existing occurrences of these two language names. Regards, --Michawiki 22:18, 8 March 2009 (UTC)

That is what the optional "-n" messages in Babel are for. Siebrand 22:23, 8 March 2009 (UTC)
Ah, thank you. I tried to customize the default messages but they have been pushed to the problematic messages then.That was the reason why I asked. Regards, --Michawiki 22:44, 8 March 2009 (UTC)

Thanks, but I cannot use translatewiki

You closed my bugs Bugzilla:17859, Bugzilla:17794, Bugzilla:17742, Bugzilla:17736, and told me to use translatewiki.

But translatewiki requires we "set your user interface to the language you will be working on".

You are making a big mistake thinking that everybody can work best that way.

I can't.

So my bug reports got thrown in the dumpster. Jidanni 03:30, 9 March 2009 (UTC)

OK, I can still make a contribution by mailing patches to .po files. That way I can use all my own familiar interfaces. Following the instructions on Translating:Offline, I have mailed a patch that will solve Bugzilla:17859.

However some of the other bugs involve setting up test scripts, which is beyond the scope of translate wiki.

And some of the other bugs are asking how to proceed: do you wish me to make the rash changes I propose?

So by just summarily closing all the bugs, you do not resolve the issues. Jidanni 05:57, 9 March 2009 (UTC)

What comes to scripts, I'd like to integrate them into the interface if they are made in php. – Nike 17:14, 18 March 2009 (UTC)

should leave obsolete message undeleted, and marked as obsolete instead

All obsolete message like, Sp-translate-data-SkinNamesTemplate:Msg/wrong parameter, should not be deleted, to leave the historical information in public view. The FUZZY marking the message as obsolete can be used. --Ans 06:50, 3 March 2009 (UTC)

What is the reason why those obsolete messages has been deleted? Why not leave them undeleted, for historical reason? --Ans 06:56, 9 March 2009 (UTC)

Usually obsoleted messages are not deleted. – Nike 14:47, 13 March 2009 (UTC)
So why the obsolete message like "Sp-translate-xxx/xx" has been deleted? --Ans 14:27, 16 March 2009 (UTC)
These were not message in MediaWiki, nor any of its extensions. They were only internal to translatewiki.net (Betawiki, at that time) but they were kept in the MediaWiki namespace, which has a potential to name conflicts. Maybe, this was the reason for their deletion. Their content (skin names) has been moved to some other place, meanwhile, I think. Maybe the deleted old versions could be restored, and renamed to their current names, if you really care to have their history available. --Purodha Blissenbach 09:05, 17 March 2009 (UTC)
Yeah they were special messages, of which the contents are now in many different messages. – Nike 17:13, 18 March 2009 (UTC)
Is there any problem with them, if I would request undeletion of all these messages? --Ans 08:53, 26 March 2009 (UTC)
Lot's of work. – Nike 13:07, 26 March 2009 (UTC)
Ok, then I would request undeletion of Sp-translate-xxx for only Thai language (/th). Thank you. --Ans 05:31, 31 March 2009 (UTC)

Upper Sorbian Flagged-Revs messages are used for Lower Sorbian Flagged revisions Stabilization messages

If I use preview for following Lower Sorbian messages (Flagged Revisions - Stabilization)

Stabilization-text ("Change the settings below to adjust how the stable version of $1 is selected and displayed."), Stabilization-select1 ("Latest quality version; then latest sighted one"), Stabilization-select2 ("Latest checked version") and Stabilization-select3 ("Latest pristine version; then latest quality one; then latest sighted one") which use the Flagged Revisions - Flagged Revs messages

the last mentioned messages use the Upper Sorbian text instead of the Lower Sorbian:

  • revreview-lev-sightedTemplate:Msg/wrong parameter uses Upper Sorbian přehladana instead of Lower Sorbian pśeglědana
  • Revreview-lev-quality ("quality") uses Upper Sorbian kwalitna (I'm sure that's Upper Sorbian but here Lower Sorbian has the same text, so it seems that there isn't any difference)
  • Revreview-lev-pristine ("pristine") uses Upper Sorbian prěnjotna instead of Lower Sorbian spoćetna

Besides I don't find good that there are special messages for simple adjectives where just one grammatical form is possible. There are languages that have declension like Upper and Lower Sorbian. Regards, --Michawiki 22:09, 10 March 2009 (UTC)

I've just seen it's because I was using Upper Sorbian as GUI language for translatewiki.net. I switched to Lower Sorbian and then the respective words were in Lower Sorbian as it should be. Regards, --Michawiki 22:23, 10 March 2009 (UTC)
I've made the message names links so as to ease looking them up. --Purodha Blissenbach 06:39, 11 March 2009 (UTC)
IRCC the developer made some tweaks to the messages. Is it now ok or not? – Nike 14:15, 13 March 2009 (UTC)

Daddio skin

I have realized that new Daddio skin has been added to the software. It would be nice to have localization support for it, too. Thanks. --fryed-peach 06:50, 11 March 2009 (UTC)

Which part of it is not localisable? Do you mean the name of it? – Nike 14:13, 13 March 2009 (UTC)
Yes, its name on Special:Preferences. Maybe that on a default comment in .css and .js, too? --fryed-peach 07:34, 16 March 2009 (UTC)
Looks like we need to add them. – Nike 17:12, 18 March 2009 (UTC)
Taken out of core and now available as an extension. No longer relevant. Siebrand 16:25, 29 March 2009 (UTC)

MediaWiki:Sharedupload

Why is en:MediaWiki:Sharedupload/nds different from MediaWiki:Sharedupload/nds? Why doesn't it show a link to Commons? --::Slomox:: >< 11:12, 11 March 2009 (UTC)

Likely to be http://translatewiki.net/wiki/FAQ#I_have_changed_a_message_but_the_old_one_is_still_appearing_on_my_home_wiki . – 14:38, 13 March 2009 (UTC)
There were no updates since a month? --::Slomox:: >< 11:05, 15 March 2009 (UTC)
Yeah, should be live now. Or not, dunno if it should be. – Nike 17:10, 18 March 2009 (UTC)
Fixed now. – Nike 08:19, 28 March 2009 (UTC)

Expansion depth limit exceeded

Error message here: "Merge account across wikis of {{Expansion depth limit exceeded}}" --Meno25 20:44, 11 March 2009 (UTC)

I don't see anything at there. – Nike 07:49, 12 March 2009 (UTC)

Look in the "Information about the group" box. Full text is:

Information about the group
Merge account across wikis of {{Expansion depth limit exceeded}} 

--Meno25 21:49, 18 March 2009 (UTC)

Works for us. Cannot reproduce. Siebrand 16:26, 29 March 2009 (UTC)

about {{PLURAL}}

According to FAQ#An English message contains a PLURAL function but it doesn't need a PLURAL function in my language,

If your language does not need the PLURAL function at all, then explain this on the Support page. You may be able to get the check software to ignore missing PLURALs in your language.

Thai language has no plural form. However, there's some case that the English message use {{PLURAL}}, to display the word "one" instead of "1". Thai message may also use {{PLURAL}} to display the word "หนึ่ง" instead of "1" as in English.

For example,

  1. {{PLURAL:$1|a dog|$1 dogs}} --> thai: {{PLURAL:$1|สุนัขตัวหนึ่ง|สุนัข $1 ตัว}}
  2. {{PLURAL:$1|one dog|$1 dogs}} --> thai: {{PLURAL:$1|สุนัขหนึ่งตัว|สุนัข $1 ตัว}}
  3. $1 {{PLURAL:$1|dog|dogs}} --> thai: สุนัข $1 ตัว

What should we do with this?

  1. let the check software to ignore the missing PLURAL in Thai, and never use PLURAL in Thai at all?
  2. not ignore the missing PLURAL, and use {{PLURAL:$1|สุนัข 1 ตัว}} for the third case above? (always use PLURAL in Thai)
  3. not ignore the missing PLURAL, but not use PLURAL for the third case above (use PLURAL in Thai only where applicable), and ignore the warning from the check software?
  4. let the check software to ignore the missing PLURAL in Thai, but use PLURAL in Thai where applicable? (Ans 14:14, 16 March 2009 (UTC))

--Ans 08:57, 12 March 2009 (UTC)

Given the limitations of the current system, I propose solution where warnings about plural are not produced, and plural used where it makes sense. This has the advantage of not hiding other problematic messages in the mass. – Nike 11:21, 12 March 2009 (UTC)
Do you mean the 2nd solution? Is there any disadvantage of using {{PLURAL:$1|xxx}} in the 2nd solution? --Ans 14:14, 16 March 2009 (UTC)
Seem like that, there's no any substantial disadvantage of using {{PLURAL:$1|xxx}} in language with no plural form. Thank you. --Ans 05:39, 31 March 2009 (UTC)
The same goes for Japanese. I recommend the 3rd solution, just ignore warnings from the software. --fryed-peach 15:21, 12 March 2009 (UTC)
Which has the disadvantage of hiding the real problematic messages in the mass. – Nike 14:10, 13 March 2009 (UTC)
Does the commit software do anything different between the messages marked as problematic and not marked as problematic? --Ans 14:14, 16 March 2009 (UTC)
No. – Nike 08:32, 17 March 2009 (UTC)

Can we get the software to so ignore PLURAL-related errors in Bahasa Melayu (ms) and Bahasa Indonesia (id) too? ...Aurora... 08:05, 28 March 2009 (UTC)

Low priority feature request. Siebrand 16:27, 29 March 2009 (UTC)

User fallback languages coming

I have a solution allowing users to specify up to an installable number of own fallback languages in their preferences. Not done (yet) is making message retrieval use them. Before adding that, I would like to implement that existing messages from users fallback languages are included in the edit screen when translating.

Question: which messages are to be shown, and in which order, respectively?

  1. fallback languages of the target language that is being translated to,
  2. fallback languages currently shown with the target language (from a local list in Extension:Translate)
  3. user fallback languages.

Suggestion: User fallback languages (2) only. If none are specified, then the local list (2) of the extension merged with the languages list (1) as it currently is. --Purodha Blissenbach 03:02, 13 March 2009 (UTC)

I'm not sure it is a good idea to bind together the fallback system of MediaWiki and the languages shown to the translators. – Nike 14:07, 13 March 2009 (UTC)
That would mean having a 2nd set of languages that users can specify, pertaining only to Extension:Translate? That's likely easily implemented. Btw. I would like my code tested by a broader user base than myself :-) but am a bit hesitant to just commit it to svn without the message retrieval part. Is there an easy way, via patch, branch, etc. to provide it for testing here at translatewiki.net, would you want to try it? Or do you recommend committing rightaway? --Purodha Blissenbach 18:08, 13 March 2009 (UTC)
If you are uncertain about the quality of your code, or a solution, either create a branch and apply the patch there, or create a bugzilla and attached the patch for review. Siebrand 16:30, 29 March 2009 (UTC)
Is there a guide, or an explanation, how to create a branch in MediaWiki svn? Parts of core, and parts of two extension have to go there. --Purodha Blissenbach 00:41, 30 March 2009 (UTC)

No used message

Message Mediawiki:Logouttitle is not used in current PHP code. Sp5uhe 20:03, 14 March 2009 (UTC)

Done Done mwr:49016. Siebrand 16:59, 29 March 2009 (UTC)

Navigating messages when editing

Existing (translated) message have three very helpful navigation links on their screens, "previous", "next", and "back to list" — only untranslated (not yet created) messages do not have them. Can they be added there, too? Often, I quickly want to page back and forth between related messages so as to find be best possible, and most consistent, wording for all of them, before I go ahead typing, thus possibly avoiding repeated edits of the same messages in a very short time. This is not of high priority, though, because when really uncertain, I can as well copy&paste the untranslated messages, and save them hand-fuzzyied, which gets me the navigation links. Thank you. --Purodha Blissenbach 08:58, 16 March 2009 (UTC)

Where no translation exists, we do nothing special. Also, I do not understand the exact use case of jumping back and forth between existing and non-existing messages. Please elaborate. Siebrand 17:02, 29 March 2009 (UTC)
As for me, when I found a message needing a translation or update at Special:LanguageStats, I jump to the message but it is usually hard to get the context for it immediately, so then jump to next messages and see existing translations for the feature in which the message is used, for making a consistent translation. --fryed-peach 17:31, 29 March 2009 (UTC)
Where are these 'very helpful navigation links'? - I do not see them on the screen of existing (translated) messages which I am accessing via the translation tool. Am I using the wrong skin to see these (I use Monobook)? Lloffiwr 19:14, 29 March 2009 (UTC)
Edit page screenshot.
@Lloffiwr:
I most usually use Monobook, as well.
See the attached image of a screenshot, where we have marked them with a yellow marker pen.
I hope that helps to locate them.Smiley.svg
--Purodha Blissenbach 10:37, 31 March 2009 (UTC)
Thank you for the screenshot - I have found the links on the 'preview' page (right under my nose!) and will certainly use them. Lloffiwr 21:24, 31 March 2009 (UTC)

Fuzzy followed by whitespace

When Fuzzy marks are stripped for export, whitespace following them should be, too. Currently, messages cannot have leading whitespace, except, when sneaking through behind a Fuzzy mark. --Purodha Blissenbach 09:06, 16 March 2009 (UTC)

Message can and some need to have leading whitespace (only spaces, newlines are known to cause trouble) – Nike 12:56, 16 March 2009 (UTC)
egrep " => ['\"] " *En.php
'filename-prefix-blacklist'   => ' #<!-- leave this line exactly as it is --> <pre>
'upload_source_url'  => ' (a valid, publicly accessible URL)',
'upload_source_file' => ' (a file on your computer)',
'external_image_whitelist' => ' #Leave this line exactly as it is<pre>
  • Submitted new patch stripping only leading line-endings, vertical tabs, and NULs. --Purodha Blissenbach 08:29, 17 March 2009 (UTC)

Multipleupload-text

This message should use PLURAL for parameter $1. --EugeneZelenko 14:05, 19 March 2009 (UTC)

Done Done This message uses addWikiMsg() to add it. It already supports plural. Siebrand 17:07, 29 March 2009 (UTC)

intranslatable

The text 'Browse' in the message is browser and browser-language dependant, and thus cannot be translated, or localized. It needs to be replaced by something better. --Purodha Blissenbach 10:09, 20 March 2009 (UTC)

Please make a suggestion. Siebrand 19:04, 28 March 2009 (UTC)

Grouppermissions-sp-header

I believe, in Grouppermissions-sp-header ("You may use this page to manage how permissions are sorted and add new permissions. Hover over a permission to read its description"), the word "hover" in english, or the translations referring to "mouse" are problematic, because too much depending on browser specifics, which may vary. I've no better suggestion, however. :-(( --Purodha Blissenbach 02:33, 22 March 2009 (UTC)

You can refer to the tooltip concept. Siebrand 17:10, 29 March 2009 (UTC)

Gift received body

What are variables in Gift received body ("Hi $1.

$2 just sent you the $3 gift on translatewiki.net.

Want to read the note $2 left you and see your gift? Click the link below:

$4

We hope you like it!

Thanks,


The translatewiki.net team

---

Hey, want to stop getting emails from us?

Click $5 and change your settings to disable email notifications.")? --fryed-peach 14:18, 22 March 2009 (UTC)

Done Done Siebrand 16:23, 29 March 2009 (UTC)

Configure-ext-settings-dep-error

Where can we configure the texts "string", "interger", or "boolean" being inserted in Configure-ext-settings-dep-error ("$1: required value: $2, current value: $3"), according to the description? I expect them to need to have grammatical gender dependent articles added, but I could not find such texts in the messages of this extension. --Purodha Blissenbach 15:59, 25 March 2009 (UTC)

Create a bugzilla. No idea what you want here. It is a very technical message targeted at the more tech savvy. Siebrand 16:24, 29 March 2009 (UTC)
My understanding is that "string", "integer" or "boolean" is not the literal text to be inserted, but just the type of data that will be inserted. – McDutchie 16:58, 1 April 2009 (UTC)

Gender support needed

Abusefilter-edit-builder-vars-user-name ("Name of the user account") does not have a user name parameter but is followed by a user name link when used. --Purodha Blissenbach 09:57, 26 March 2009 (UTC)

It is a query builder variable. Gender support does not make sense. Siebrand 17:11, 29 March 2009 (UTC)
Ok. Ok. I misinterpreted some documentation or comment text. --Purodha Blissenbach 23:05, 31 March 2009 (UTC)

Abuse filter

There are some short message strings not i18nable in Extension:Abusefilter which mainly appear as a reply to the filter load and syntax check and test filter buttons:

  • No syntax errors.
  • Syntax error: (translatable message follows)
  • BADSYNTAX

and maybe more, see Bug 18176. --Purodha Blissenbach 10:09, 26 March 2009 (UTC)

Regexblock-help

The meaning of the sentence: Note: partial IP addresses will be treated by usernames in determining blocking. is pretty unclear to me. What is to be treated by usernames? Replaced, or substituted, by usernames? Not interpreted, and thus treated as if they were usernames? --Purodha Blissenbach 10:35, 26 March 2009 (UTC)

Regexblock-view-blocked

The meaning of Regexblock-view-blocked ("View blocked by:") is a bit in the dark to me. --Purodha Blissenbach 21:58, 28 March 2009 (UTC)

Have a look at the screenshot. It is followed by a dropdown list of all users who have ever used regexBlock on the wiki, allowing the viewer to filter down the list of regexBlocks (i.e. see all blocks performed by User:X if users X, Y and Z have used regexBlock tool). --Jack Phoenix (Contact) 22:11, 28 March 2009 (UTC)
Thank you. Thank you. That helped. --Purodha Blissenbach 01:55, 29 March 2009 (UTC)
Sigh, this once again is one of those things requiring an awfully long and weird translation to be useful and grammatically right, since programmers forgot to give us two strings, one before, and one following the input field. :-(

date/time

It is scheduled to start on $2 at $3."), the $1 should have date and time separated as well. --Purodha Blissenbach 00:36, 30 March 2009 (UTC)
Bug 18271, Done Done with Revision 49059. --Purodha Blissenbach 06:41, 31 March 2009 (UTC)

messages needing GENDER enabled

In Stableversions-review ("Reviewed on $1 by $2"), the message documentation said that, $2 was a user name. That is not true. Is is a compound of several links. Thus, the user name needs to be passed to the message in an extra parameter, and GENDER availability checked. --Purodha Blissenbach 09:02, 31 March 2009 (UTC)

PLURAL support needed

Extension: Wikidata Language Manager

I believe, the word "Words" in Datasearch match words ("Expressions matching $1 and their associated meanings"), and Datasearch match words lang ("Expressions in $1 matching $2 and their associated meanings"), should be using PLURAL. --Purodha Blissenbach 01:51, 29 March 2009 (UTC)

Extension: Flagged Revisions

A link is given to the latest revision of that level.") needs PLURAL support. --Purodha Blissenbach 11:47, 29 March 2009 (UTC)

Extension:Abusefilter

Abusefilter-exception-notenoughargs ("Not enough arguments to function $2 called at character $1. Expected $3 arguments, got $4"), for $3 and $4. --Purodha Blissenbach 11:39, 1 April 2009 (UTC)

stableversions

Stableversions ("View reviewed versions") says "View stable versions". Should that not rather be "View stable revisions" so as to use a consistent wording throughout the group of messages? --Purodha Blissenbach 09:47, 29 March 2009 (UTC)

Actually I wish they would consistently use "version" instead of "revision" in that context. The English word "revision" can also mean "review" as in "act/result of reviewing/revising", which is ambiguous. In Interlingua and (as far as I can see) all Latin languages this is even more problematic as "review" and "revision" are both translated as "revision". So I try to consistently translate something like "stable revision" with "version stabile" to avoid ambiguity. – McDutchie 13:53, 29 March 2009 (UTC)
We do not have a distinction between "revision" (as of history/revision, or r4711 of a program) and "version" - there is only one word, close to "version". We have a word similar to "revision" but that's meaning "fiscal check", "controlling" and the like. Instead of "a revision having been made" in the 2nd sense, we talk of "one has throughly looked/read through something", similar to inspecting, and since this has no other effect than enlightening the reader, we must also make explicit that, a record has been taken in the form of a value mark that was attached to that something. :-) Believe me, it's a lot of additional words. Maybe, we can lobby for using "version" in the english text consistently, and avoid "revision" (as of r12345) altogether inside MediaWiki? --Purodha Blissenbach 14:27, 29 March 2009 (UTC)

Stabilization-restrict

The message Stabilization-restrict ("Review/auto-review restrictions") is ambigious. It says: "Auto-review restrictions". Does this mean:

  1. "automatically review the restrictions", or
  2. "restrictions on automatic reviews"?

Existing translations in various languages seem to disagree on this. TIA – McDutchie 13:57, 29 March 2009 (UTC)

More candidates to use Ellipsis ("...")

Moredotdotdot ("More..."), Resetpass success ("Your password has been changed successfully!

Now logging you in..."), Iteminvalidname ("Problem with item "$1", invalid name..."), Watching ("Watching..."), Unwatching ("Unwatching..."), Importstart ("Importing pages..."), Ow conceptmapping help ("

possible actions:

  • &action=insert&<data_context_prefix>=<defined_id>&... insert a mapping
  • &action=get&concept=<concept_id> read a mapping back
  • &action=list_sets return a list of possible data context prefixes and what they refer to.
  • &action=get_associated&dm=<defined_meaning_id>&dc=<dataset_context_prefix> for one defined meaning in a concept, return all others
  • &action=help Show helpful help.

"), Refreshspecial-slave-lagged ("Slave lagged, waiting..."), Refreshspecial-reconnecting ("Connection failed, reconnecting in 10 seconds..."), Recordadmin-needscontent ("Add content..."), Contrib-tracking-submitting ("Submitting to payment processor..."), Cite error references invalid parameters group ("Invalid parameter in <references> tag"), Boardvote intro ("Welcome to the 2008 election for the Wikimedia Board of Trustees.

We are voting for one person to represent the community of users on the various Wikimedia projects. They will help to determine the future direction that the Wikimedia projects will take, individually and as a group, and represent your interests and concerns to the Board of Trustees. They will decide on ways to generate income and the allocation of moneys raised.

Please read the candidates' statements and responses to queries carefully before voting. Each of the candidates is a respected user, who has contributed considerable time and effort to making these projects a welcoming environment committed to the pursuit and free distribution of human knowledge.

Please rank the candidates according to your preferences by filling in a number beside the box (1 = favourite candidate, 2 = second favourite, …). You may give the same preference to more than one candidate and may keep candidates unranked. It is presumed that you prefer all ranked candidates to all not ranked candidates and that you are indifferent between all not ranked candidates.

The winner of the election will be calculated using the Schulze method. For more information, see the official election pages.

For more information, see:

left empty.

"), Imstatus icq style ("a number ranging from 0 to 26 (yes, there are 27 available styles)."), Revreview-submitting ("Submitting..."), Readerfeedback-submitting ("Submitting …"), [1] ("Import"), Configure-setting-wgRawHtml ("Allow raw, unchecked HTML in <html>...</html> sections"), Configure-setting-wgAllowCategorizedRecentChanges ("Allow to filter the recent changes by a category or one of its sub(subsubsub...)categories"), Communityvoice-ratings-scale-status-sending ("Sending..."). --EugeneZelenko 15:25, 29 March 2009 (UTC)

Let's not. The messages look ugly and novice translations get confused. Just put a real ellipsis in there for de source (English) message and be done with it. An English fallback with a localised ellipsis also looks stupid. Siebrand 16:14, 29 March 2009 (UTC)
You are right. I think it is the best to use the right ellipsis in mwr:48978 instead of the message. Please FUZZY only message with the 'wrong' ellipsis. Thanks. Der Umherirrende 17:12, 29 March 2009 (UTC)
I'm not fuzzying the change I made here. It's a very small issue that should be corrected in a review round. Less than 20 translation communities here are at that stage. Siebrand 17:50, 29 March 2009 (UTC)
1) We should have an {{int: }} equivalent using the same language as the msg it is being used in. Rarely needed, but it would solve the above namespace issue, and would allow the right ellipses to be inserted here.
Slightly more general: {{int2:message-name|lang-code}} which allows lang-code to be left out and thus 'inherited' from the language being in effect at the place of use of int2.
2) I agree with using plain ellipsis in the original messages. --Purodha Blissenbach 07:19, 31 March 2009 (UTC)

Votic

There is a request to have a Wikipedia in Votic. In translatewiki.net someone may do the work. We only submit to SVN when more then 50% of the most used messages are localised. So as there is this request, I do ask for Votic to be enabled. Only to be submitted at 50%. Thanks, GerardM 11:04, 30 March 2009 (UTC)

Done DoneNike 20:26, 31 March 2009 (UTC)
  • "stupid question" (for the FAQ page) - Why are we waiting for 50% - avoid never continued tasks filling the svn repository? - any other reasons? Tx. --Purodha Blissenbach 07:04, 31 March 2009 (UTC)
Because anything less is not even useful? – Nike 07:18, 31 March 2009 (UTC)
I dunno. Thats a question: Users at the incubator, or any other striving new project outside the wmf scope, may feel very happy to see even the first little beginnings showing up at their wiki. Especially so, when some basics need to be discussed, such as consistent choices of one word out of a group of synonyms, or, for languages "untechnical by nature", such as vernacular, ancient, or some 3rd world languages, which words or expressions to strech to include special computerese/mediawikinese terms, e.g. file, user, namespace. Of course, this can all be had and done here on translatewiki.net. Only people need to be motivated to come here, too. When starting a new test Wikipedia, shortly before Betawiki began, and long before incubator, I realized that sending people to Commons for file uploads was not a good idea and not working well. So I am afraid that some may be hesitant to come here. Which in turn puts up he question: Why not let them stay there, and let them have all they need, there? --Purodha Blissenbach 07:39, 31 March 2009 (UTC)

Lqt newer ("← newer") and Lqt older ("older →")

I think ← and → should be used in these message for consistency. --EugeneZelenko 14:18, 30 March 2009 (UTC)

Lqt protectedfromreply ("This thread has been $1 from being replied to.") and Lqt protectedfromreply link ("protected")

Should be combined in one sentence to avoid broken translations. --EugeneZelenko 14:02, 31 March 2009 (UTC)

Same for Lqt move torename ("To rename this thread, $1 and change the 'Subject' field.") and Lqt move torename edit ("edit it"). --EugeneZelenko 14:12, 31 March 2009 (UTC)

== Lqt summary notice ("There have been no changes to this discussion for at least $2 days. If it is concluded, you may want to $1.") ==

Should use PLURAL for parameter $2. Parameter $1 is likely to cause broken sentence. --EugeneZelenko 14:08, 31 March 2009 (UTC)

"feature" request

What is "this feature" in the message Coll-popup help text ("To deactivate this feature click "Clear book" in the "Create a book" box")? --Purodha Blissenbach 22:56, 31 March 2009 (UTC)

aqo language request

Have a nice new month! This is a request to add the native language of the Central Antartic tribes, the Agnupiaq-Algolgine, having ISO language code aqo, to translatewiki.net. Today I met a very kind native speaker during a flight, who bekame absolutely eager and determined to translate "Wikipedias Interface" once he had heared that this is possible, and how it works. He'll be registering here as soon as possible when having reached a place with internet access on his journey, likely tomorrow, he said. --Purodha Blissenbach 00:21, 1 April 2009 (UTC)

Extension:Securepoll

Is Securepoll-invalid-vote (""$1" is not a valid vote ID") referring to a single vote of a single user? --Purodha Blissenbach 09:30, 1 April 2009 (UTC)

Secure Poll

In which wikimedia project this extension is used? --Metalhead 10:20, 1 April 2009 (UTC)

None yet. – Nike 10:36, 1 April 2009 (UTC)
Is it planned? --Metalhead 10:54, 1 April 2009 (UTC)
Yes. – Nike 11:35, 1 April 2009 (UTC)
I wish, it was on http://test.wikipedia.org/ so as to have a reference installation for better checks, how messages are being used. Is that possible? (btw. same with regexBlock) --Purodha Blissenbach 11:37, 1 April 2009 (UTC)
As assume it will be enabled tomorrow for the Licensing update. Raymond 12:42, 1 April 2009 (UTC)

Coll-popup help text ("To deactivate this feature click "Clear book" in the "Create a book" box")

I think will be good idea to use int: to refer to Coll-clear collection ("Clear book") and Coll-create a book ("Create a book") instead of plain text to keep translations consistent--EugeneZelenko 13:43, 1 April 2009 (UTC)