Problems using translatewiki.net? You have read the introduction and you do not know what to do? Have a feature request? Write your question below. Please link to a particular message if your question is about it.
![]() Prime pagina |
![]() Precedente pagina |
![]() Sequente pagina |
![]() Ultime pagina |
Config-cc-not-chosen ("Selige le licentia Creative Commons que tu prefere e clicca "proceder".")
Should refer to button name with int: for translation consistency. Will be good idea to check other messages of this extension for similar issues (search for click).
I've noticed a couple of bugs in Translate extension interface in right-to-left languages. The first is shown in this screenshot where the brackets at the end of the original message are shown in the beginning. The second is in this screenshot where the link in the document message is at the beginning instead of the end. This probably needs a CSS fix.
OK, sad to hear. I'm not that great with RTL and CSS. Please suggest updates to our CSS file.
Do you have the RTL gadget enabled in your preferences?
It seems that the RTL interface is enabled by default for Arabic. Turning the gadget on/off does not make any difference on the Interface (Tried on Firefox 4 Beta 3 and Chromium 6.0.472.36), and they both have the same issue.
Could you explain the meaning of "Augmentation" in context of Reflect-desc ("Augmentation de commentos in discussiones")
I translated it as "extension".
The German translation says something like: 'Extends the possibilities to use threaded comments on discussion pages'.
The Dutch translation back into English reads "Extension of structured discussion".
IMO, the description says nothing, and should be rewritten.
According to http://www.mediawiki.org/wiki/Extension:Reflect this is an extension dependent on LiquidThreads that adds a column where users can summarize an existing threaded discussion using bullet points. So I would suggest something like:
Adds a column to LiquidThreads talk pages in which users can make bullet point summaries of existing discussions
1) Guiding translators to various sister projects like commons, meta, and media wiki becomes scattered and without control so is it possible to bring some levels of their translations can be done here at translate wiki itself , we will benefit with some easy tools available over here .
2) There is one good mozill addon [1] Weekedit 2.0.2 by Olier Raby the tools are very usefull for editors Mr.Olier Raby has made localisation possible on some other website. The only thing is again our activity becomes scattered is it possible to request them too take translations from translate wiki itself .
08:03, 25 August 2010 (UTC)
I think we should respect, cherish and nurish the different communities; you can't do everything in one wiki. IMO that is confusing.
What we can do is try and get the processes that support translation lined up. We - developers of the Translate extension - think that page translation in wikis that have a lot of static documentation can benifit hugely from the structured process that the Page Translation feature offers. Within Wikimedia I indeed see use cases in mw:, meta: and commons:. However, there are two main issues preventing implementation of the Translate extension within Wikimedia: our code has not been audited by a senior MediaWiki developer on the Wikimedia pay-roll, which is a requirement for implementation, and the process leaders for translation within the aforementioned Wikimedia communities are either not aware of the functionality that Translate has to offer, or they think they can do without.
The first issue - code audit - is something that's on the roadmap. Ariel Glenn allegedly has planned to do some auditing, although I doubt his hopefully positive verdict will suffice; he may not be senior enough. The second is something you, as a community member of both translatewiki.net and possibly various Wikimedia projects can do something about: advocate the use of the feature, find a relevant group of users supporting use on the Page Translation feature in another wiki, have a poll, create a bugzilla: request for installation and ask as many users as possbile to vote for this issue. Do realise this is no guarantee for success, but every little bit may help...
As for supporting FireFox extensions: that may be possible, although I have no idea of the file format for localisation of Firefox extensions. We have a special page with the requirements for adding new projects to translatewiki.net: New project. Please give it a read, get a developer of the product involved and maybe we can make it happen.
Thanks for your reply and guidance, I am one of the very vocal proponent of local level indipendance for communities as you said I belive in we should respect, cherish and nurish the different communities.
माहीतगार 05:06, 27 August 2010 (UTC)
Btw, the Firefox extensions usually use a .dtd file for their localisations, I think because a lot is done with XML and such stuff in Firefox. They then define entities in there which they use in the programm itself. For example:
<!ENTITY some.message "something"> <!ENTITY another.message "something else">
Looks like we can do that with the FFS we have for Okawix DTD. Sample:
<!-- # Messages for Afrikaans (Afrikaans) # Exported from translatewiki.net # Author: Naudefj --> <!ENTITY okawix.title "Okawix &okawix.vernum; - Wikipedia-blaaier"> <!ENTITY okawix.back "Terug"> <!ENTITY okawix.forward "Vorentoe"> <!ENTITY okawix.home "Tuis"> <!ENTITY okawix.search "Soek">
In Centralnotice-start-hour ("Hora de initio (UTC)") can we have the abbreviation UTC instead of GMT in the original English message, to internationalise it for English readers?
Hmm, the difference is that UTC has no summer time and GMT has, right?
Neither UTC nor GMT have summer time. (In the UK we would use the abbreviation BST - British Summer Time - and in the US I believe it is DST - Daylight Saving Time - during summer time) The difference between them is explained here. I was under the impression that UTC is preferred for 'international' use - see here.
In the translation editor for MediaWiki:Categorywatch-emailbody/en the English source message is not shown, although the translations in the assistant languages are. This is the only message having this problem that I have found this afternoon.
Don't know how you got there, but that does not appear to be a translatable unit.
Obsolete messages show up in search results all the time. The signs of obsolescence are not obvious to the non-initiated. Since your policy is not to clean them up, perhaps there should be an indication on the edit page or window that a message has been deactivated for translation.
In which use case do obsolete messages show up all the time? The only thing I can think of is in TM results. And that's exactly where we want to keep them for a while.
I came across this message when reviewing recent changes to cy - user Xxglennxx had changed this message. I imagine that he had run a search for the word 'gwylio' - there is a whole batch of changes related to this word.
Well, I know that you can also sometimes come across unused messages through an {{Identical}} template. But since that's a template hack at the moment anyway, the proper solution should probably solve this problem.
When searching for any keyword using the search box at the top left, obsolete messages containing the keyword in question will show up in the search results the same way current ones do, with no way to distinguish between them from the results list.
You can distinguish them on the translation page itself by the absence of an English original (and in the classic/non-Javascript editor, by the absence of the "In other languages" link at the left), but for most users, this is confusing and clarifies nothing.
I do agree with keeping obsolete messages. They are useful for translation memory purposes if nothing else. But I think it would be good to have some clear way of distinguishing them from current messages, in search results and in the edit pages themselves.
Have amended the FAQ on this. Am not sure that the sentence 'Obsolete messages are not included in the translation tool or in the localisation statistics' is correct.
It can be corrected in the message group for Special:FirstSteps]. I have fixed the link, but maybe you want to do some more review.
In Checkuser-massblock-text ("Le contos seligite essera blocate infinitemente, con le blocada automatic activate e le creation de contos disactivate. Le adresses IP essera blocate durante 1 septimana pro usatores IP solmente e con le creation de contos disactivate.") I am having trouble understanding "for IP users only".
Again you appear to have stumbled on a non-key. Although possibly this message was translatable once, it is not longer.
How about change the link called Random Message? now it just like Random article in wikipedia, which can take us to a random message in random language.
I think it should only take translators to an message which is untranslated in current user language, and let the translator to translate it.
Sometimes I just messed up at Special:LanguageStats, and I hate choosing any of them! Now my day starts with go to Special:LanguageStats, and I hope one day I just need to go to Special:Random and all I need to do is clicking "Save and open next random".
Everyone's day should start with Special:LanguageStats! That's what it was designed for (or what it turned out to be - whatever you choose). If you would like to pick another entry point for translatewiki.net, you can also pick Project list. I don't see any value in particular to your feature request.
Then how about make the filter of languagestats more powerful? now it can only hide those project that is completely finish, but I think more filter is needed, like show all project that has no translation yet, or hide all project that is in green color already, or only show projects that has 10% or more out-dated etc. that'll be very useful.
That's indeed planned. We want to add drilldown functionality into it. With regards to message group properties, this is already present, but functionally is has not been added yet. It does not have the highest priority, though. If you are able to develop this yourself, please let us know, because we would be happy to help you get on your way. If you can sponsor development considerably, we would also like to hear from you.
Well, I'll waiting for this function but in fact it's not really in need. So take it easy, everyone still live well without it.
There's an easy way to develop this function, that is to use an input box and let user to type in something like "(% uncompleted%>50)&&((%outdated%>20)||(%color%!=%GREEN%))" and click submit. It's not user friendly though. Or, use javascript to let browser to operate the languagestats page, like when user choose to hide all green, the script determine and do it.
Well, another way is to use Special:Translate, where all translatable stuff is listed. You can just choose a random item from there and check it out. I sometimes do this.
In some languages of the Caucasus the letter "Palochka" is used - 'Ӏ'. It is similar in appearance to Latin I and to the Cyrillic "Ukrainian" 'I', but it is a distinct character.
In many messages that were translated to language kbd-cyrl (Kabardian Cyrillic) the capital Latin letter 'I' was used instead of the Palochka. Though technically wrong, it is usually hardly distinguishable from the real palochka. In MediaWiki, however, many messages are forced to all-lowercase, and then the 'I' becomes an 'i', and this is completely wrong, because the palochka is always capital.
Is it possible to replace capital 'I' to 'Ӏ' in these messages using a bot? It should be replaced only if all the other letters in the word are Cyrillic, although the palochka may appear more than once in a word.
Thank you.
If you know how to use pywikipediabot, I can provide you with a list of pages so you can run a bot on it. Is that acceptable?
I can do it once, but people may write messages with Latin I again, because it is quite common for speakers of these languages to do it. Is it possible to make a bot that will run automatically every now and then?
Nope. As a language community you are responsible for the quality of your translations. We can assist where we can, but this is out of scope. I suggest you use the talk page of your language portal, and talk to the other translators for your language.
OK. Can you send me that list, then?
http://translatewiki.net/static/temp/kbd-cyrl.txt
CSV with namespace/pagename.
I have just lost the customized sidebar; it seems the sidebar is now using the UI language (so I get the default uncustomized MediaWiki:Sidebar/cs). Maybe MediaWiki:Sidebar has been added to $wgForceUIMsgAsContentMsg?
No, it hasn't. Sometimes it just acts up :(. Making a null edit to MediaWiki:Sidebar usually fixes it.
I've found this extension yesterday and looked at some of its translations and I noticed something there: The extension currently uses different messages when you change only one author and when you change multiple authors (changeauthor-changeauthors-multi, changeauthor-explanation-multi, changeauthor-changeauthors-single and changeauthor-explanation-single. I don't think that should be done, because plural rules differ from language to language. When the plural in English is used, some languages might still be at the singular. Also, in the messages I think singular/plural actually doesn't matter at all, the people will get it like that. Thus, I'd solely use changeauthor-explanation-multi and changeauthor-changeauthors-multi when changing an author (and remove plural there).
Independent from the first concern, changeauthor-explanation-multi and changeauthor-explanation-single make hard coded button label reference, which should be replaced with int:
changeauthor-comment ("Commento:") looks like something where you write why you changed the author and such fields are usually called "reason".
Could we establish as standard operating procedure that when new messages are brought in to translatewiki, and they already have translations in the source project, all the imported translations be fuzzied? It would force them to appear in the translation tool, otherwise we just don't know they came in. And allow us to do a simple verification that they're all correct.
I ask this because the Shapado messages came in with pt translations that are mostly in English. So none appeared in the translation tool. I was aware of this at the time and checked all the message groups manually. But just hit (totally by accident) upon the Shapado-Wiki group which is still in English. Must have missed it then, or something. Now I'll go back and check all Shapado groups just to be sure.
The other day I found (totally by accident) that MediaWiki:Wm-license-licensing-update-text/pt had been brought in, no fuzzy. But it is wrong, it wasn't written by a portuguese speaker, and needed correction.
It's not a terrible problem, but do you see the issue? It's like I need to chase these things everywhere, just in case, instead of just having them brought to translators.
Would fuzzying all imported translations cause major issues with commits? Also, don't know how others feel about this, any opinions?
Maybe it would help in the short term, but it could add extra load to the staff who import those messages. In the long term we should have a review system (custom configuration of flagged revs or something else).
Ok. While on this topic, another thing that translators can find useful is to review regularly the creations and changes of /qqq (documentation) messages. We all make assumptions when translating, many times its impossible to clear out all possible doubts. Sometimes, when a /qqq is created or changed, we verify that those assumptions were incorrect. But we don't know that the /qqq was created or changed, so it will go unnoticed. To check this, visit regularly the page:
http://translatewiki.net/w/i.php?title=Special:RecentChanges&translations=only&trailer=/qqq
That's a good idea! We could try to to come up with ways to make it easier for translators to follow changes in message documentation or how to make it more prominent.
One that comes to mind would to add a "Documentation changes" link to the "Recent changes" section of the sidebar. It already has three filters of Special:RecentChanges, and this would be a fourth.
Edit summaries from the software usually don't use dots at the end, see for example the auto summaries, undo-summary ("Annullava le version $1 per $2 (Discussion | contribs)"), revertpage ("Reverteva modificationes per $2 (Discussion) al ultime version per $1") and even the other summaries in Liquid Threads don't use dots.
I've seen that you recently added the translated magic words, namespaces and special pages to the SVN, which I have to thank for. But that again reminded me of something I noticed some time ago: I was wondering if "aliases" can be defined for magic words. You know, for namespaces and special pages, when there's a better translation, you can add a better one while still leaving the old one working. For example, in the German special pages, Special:ProtectedTitles was changed from "Blocked_titles" to "Protected_titles" in order to avoid confusion with the blocking a user thing. Now I was wondering if the same can be done with the magic words? I mean, I don't think many people out in the world are using the localized magic words, but still I wouldn't like to screw up their mark up. I've seen a translation which isn't generally bad, but which I think may be confusing (because something else in the interface is called like that) and thus not that brilliant. Of course, I'd have a talk at Portal talk:De, but first I wanted to ensure if it's possible.
Hoi, the Angika language has requested a Wikipedia, there is a localiser who wants to do the work. Could someone please enable the localisation for this language ? Thanks,
Makes direct reference to requestaccount-real ("Nomine real:"). Should be replaced with {{int:requestaccount-real}}.
Hi, would it be possible to add PLURAL to the messages Wikieditor-toolbar-tool-table-toomany ("Inserer un tabula con plus de $1 cellulas non es possibile con iste dialogo.") and Wikieditor-toolbar-tool-replace-success ("$1 reimplaciamentos facite.") at all? It makes a big difference to Manx because of complex pluralisation and mutation rules, so whatever I put looks ugly most of the time. -- Shimmin Beg 08:50, 19 August 2010 (UTC)
EDIT:Trying to correct the messages, but preview isn't working for me so I have to save it. So it looks like the ellipsis is part of the name? EDIT2:Oh, I see, it's shortening the name. I assumed the names on the table were the actual names and were just strange.
![]() Prime pagina |
![]() Precedente pagina |
![]() Sequente pagina |
![]() Ultime pagina |