View source for Thread:Support/Merged messages/reply (2)

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 Jon Harald Søby

In MediaWiki:Apihelp-bs-recentchanges-store-summary/fr

Lists all recentchanges. Allows sorting, filtering and pagination. Implements store parameters.

"Lists all recentchanges." should become "Lists all recent changes."

Submitted change on Gerrit, waiting for it to be merged.

Thanks for correction.

Change was merged, will appear here very soon.

OPEN This issue is open, waiting for action

I would like my site to go into open source translation (http://guiasdobrasil.com.br)

To translate the content of your wiki you should install the Translate extension on the wiki itself. You can use mw:MLEB to make it easier. I see Translate is already installed; now you need to prepare the pages for translation: mw:Help:Extension:Translate/Page_translation_example/pt-br.

CLOSED This issue is closed by Jon Harald Søby

MediaWiki:Thanks/en should get changed from "Send thanks" to "Sent thanks".

Would you please explain why we should do that, this is necessary to file request or even gerrit patch for this message, as the Thanks extension is one of Collaboration team works and they have right to "veto" i18n suggestions.

This should not be changed, the message is used as a header on this special page. "Sent thanks" would not be correct there.

OPEN This issue is open, waiting for action

I cannot find any information about it. Is there any?

Not really a shortcut per se, but you can just press Tab and then Enter (that works for me at least). Same amount of keystrokes as any shortcut.

CLOSED This issue is closed

Please add the possibility to translate MediaWiki to the Nogai language, as I am planning to work on Nogai Wikipedia in Incubator and will need to translate the interface for it to become a separate Wikipedia. Thanks in advance!

ISO code: nog Language self-name: Ногайша Script: Cyrillic Direction: LTR Fallback to: Russian (ru), as the language is spoken in Russia, and a vast majority of Nogai speakers are bilingual in Russian.

This language is enabled.

CLOSED This issue is closed by Nike

Hi, I am interested in developing a Nias version of Wikipedia that is currently in Incubator.

>> ISO 639-3: nia >> Language name: Nias (English), Li Niha (Nias) >> Writing system: Latin with some accented letters, written LTR

Nias is spoken in the island of Nias off Sumatra coast in Indonesia by about 1 million people. It has been studied extensively by linguists for its unique phonological inventory.

No fallback suggestion? Keep fallbacking to English, or why not fallback to e.g. French?

This language is enabled.

https://phabricator.wikimedia.org/T201138 has been created to signal back the duplication in english original messages.

Phabricator:arcanist-core-39a54b410df333dd/fr 'Functions which should should not be used because they represent the unsafe usage of dynamic strings.'

Phabricator:arcanist-core-727513c75a0ff076/fr 'Functions which should should be considered deprecated.'

Phabricator:arcanist-core-824be53866ccd70a/fr 'Classes which should should not be used because they represent the unsafe usage of dynamic strings.'

Thank you.

CLOSED This issue is closed by Jc86035

Hi. Could someone with the appropriate privileges change "topological" at MediaWiki:Kartographer-linktype-topo/en to "topographical"? This is a typo, since a "topological" map is one that represents a network without regard to actual geography. I suspect the message's translations may have to be redone as well.

I've submitted a patch to Gerrit, so this should no longer be necessary.

OPEN This issue is open, waiting for action

Please consider moving the button "Ask question", encountered on edit pages, to a better location.

From other wikis background, I'm very used to click on the "rightmost button", which is usually "Show changes". So, on translatewiki I keep clicking by error on "Ask question"! I guess I'm not the only in this situation.

If I may give a suggestion, this link could be made floating to the right, and not styled as a button, but as a link with a decorative "help" icon (i.e. " Ask question").

Personally, I have no motivation (nor time) to work on the edit page view as I consider that a legacy interface. If someone else wants to write a patch, I can review it though.

The Translate extension is more optimised for keyboard users. Personally I always use alt-shift-v so I've never suffered from this problem.

CLOSED This issue is closed by Metalhead64

Please Delete following pages. I accidentally translated those pages in Bengali.

• ১৫:৫১, ২৫ জুলাই ২০১৮ (পরিবর্তন | ইতিহাস) . . (+৭৬)‎ . . ন Osm:Geocoder.search.title.geonames reverse/qqq ‎ (বর্তমান)
• ১৫:৫১, ২৫ জুলাই ২০১৮ (পরিবর্তন | ইতিহাস) . . (+১০৩)‎ . . ন Osm:Geocoder.search.title.osm nominatim reverse/qqq ‎ (বর্তমান)
• ১৫:৫১, ২৫ জুলাই ২০১৮ (পরিবর্তন | ইতিহাস) . . (+৭৬)‎ . . ন Osm:Geocoder.search.title.geonames/qqq ‎ (বর্তমান)
• ১৫:৫১, ২৫ জুলাই ২০১৮ (পরিবর্তন | ইতিহাস) . . (+১০৩)‎ . . ন Osm:Geocoder.search.title.osm nominatim/qqq ‎ (বর্তমান)
• ১৫:৫১, ২৫ জুলাই ২০১৮ (পরিবর্তন | ইতিহাস) . . (+৭৫)‎ . . ন Osm:Geocoder.search.title.ca postcode/qqq ‎ (বর্তমান)
• ১৫:৫০, ২৫ জুলাই ২০১৮ (পরিবর্তন | ইতিহাস) . . (+৩৫)‎ . . ন Osm:Changeset.changeset.no edits/qqq ‎ (বর্তমান)
• ১৫:৫০, ২৫ জুলাই ২০১৮ (পরিবর্তন | ইতিহাস) . . (+১২)‎ . . ন Osm:Browse.timeout.type.note/qqq ‎ (বর্তমান)
• ১৫:৫০, ২৫ জুলাই ২০১৮ (পরিবর্তন | ইতিহাস) . . (+৪৯)‎ . . ন Osm:Activerecord.models.user token/qqq ‎ (বর্তমান)
• ১৫:৪৯, ২৫ জুলাই ২০১৮ (পরিবর্তন | ইতিহাস) . . (+৭৭)‎ . . ন Osm:Editor.default/qqq ‎ (বর্তমান)
• ১৫:৪৯, ২৫ জুলাই ২০১৮ (পরিবর্তন | ইতিহাস) . . (+৫৯)‎ . . ন Osm:User.lost password.title/qqq (বর্তমান)

 Done

OPEN This issue is open, waiting for action

There is an error in GRAMMAR, when used for locative in Slovene language, for example in MediaWiki:Wikibase-rcfilters-hide-wikibase-description/sl. Where could that be fixed?

? This issue is unconfirmed, still to be investigated

CLOSED This issue is closed by Framawiki

phab:T200021

Message MediaWiki:Oathauth-step1-test misses a final dot. Could someone please fix it in the OATHAuth extension?

You can see this message on wikis at Special:Two-factor authentication.

Fait !

CLOSED This issue is closed

Please fix the text on MediaWiki:Smw-prefs-general-options-disable-search-info/en- add support instead of suppport. Thanks!

Already fixed by user:kghbln: https://github.com/SemanticMediaWiki/SemanticMediaWiki/commit/230e383af2ef050ce4a773be29742807c093a926

CLOSED This issue is closed

phab:T199848

Please request correction of the english text to be translated:

Phabricator:phabricator-config-fe6cd38acc7acd6b/fr

Controll whether Phabricator allows the suppression of email from "maintenance" users.

Put 'Control' instead of 'Controll' in the original text.

Thank you

CLOSED This issue is closed by Nike

deleted

A user turned MediaWiki:Log-edit-tags into the Croatian version. Could someone delete the page or reset it to the MediaWiki default to allow it to render properly for everyone? Thanks

OPEN This issue is open, waiting for action

I've been working on TheWikipediaLibrary Card Platform https://wikipedialibrary.wmflabs.org/ for some time now, and I think we have the codebase in a place where it's ready for localization.

Message documentation:

Since this project is a Django app, which has some nice tooling around gnu gettext, we decided to bake our message documentation into our code comments and let gettext add it to the qqq po file. https://github.com/WikipediaLibrary/TWLight/blob/master/locale/qqq/LC_MESSAGES/django.po

Adding new message translations:

In addition to adding new translation files, the universe of available languages in the user preferences should be expanded by updating the LANGUAGES variable in our base settings. https://github.com/WikipediaLibrary/TWLight/blob/master/TWLight/settings/base.py A nightly build script pulls the latest changes from master and applies them so long as the changes don't fail the unit tests.

Limitations:

This app has content that lives in the database. That content is comprised of fairly large blobs of text that are not visible to Translatewiki via the code repo. We're on the hook for translation of that content, but I don't really see a good way around that. We do have some folks internal to our project willing and able to expand translation for that content. That's how we got the Finnish and French that we currently have in place.

You need more space for the login button. Finnish text is truncated.

> In addition to adding new translation files, the universe of available languages in the user preferences should be expanded by updating the LANGUAGES

Can you do that? We have no support for such automation (nor even manual process) right now.

Please consider using https://github.com/wikimedia/jquery.uls for language selection, or at least take the language names from https://github.com/wikimedia/language-data or CLDR. We don't want language names translated here again and again for different projects.

Also, is there a reason you are using the non-standard code iw for Hebrew instead of the standard one he?

No idea why iw code was chosen, but I can see that there are no actual message strings for that translation file, so I just removed that one. I fixed the login button as well.

On the way we're doing language selection: We start out by using the language requested by the browser. We record a detected language for authenticated users on first login. Users may manually set their language on their preferences page as well. We use the recorded value for interaction not tied to a browser session (emails). We're relying heavily on Django's i18n features for all of this to just work behind the scenes. Integrating the jquery library might be a difficult fit for this project, as our community expects to be able to use the site without javascript. Having said that, this looks much, much more usable than having a selection list with a ton of items in it. The current ui works for 3 languages, but I could see it getting user-hostile with 100. I'll see how feasible it is to use this when we have javascript, and use the plain form when we don't.

Very belated update: I've reworked the way we're setting the available languages so that Django is checking for the translation directories on startup. We restart the app every time we pull from the repo, so that should make for a nice automated workflow for adding new translations. Django doesn't support all of the languages listed at https://github.com/wikimedia/language-data (although we're definitely in the triple digits), so I added code to use the intersection of Django and wikimedia language codes and the autonyms from the wikimedia language data instead of English language names. I've significantly updated our database configuration so that the content that lives in the db can be localized across the entire intersection of languages without the app falling over from db column and index limitations.

What does happen when Django doesn't support a language? Do we need to add a blacklist/whitelist on our side?

The rest sounds good. Should we start checking about enabling this project on translatewiki.net?

On its own, Django was falling over dead (500) when it encountered an unknown language code. I've configured our app to just ignore unknown languages. We should probably do a whitelist so that volunteers don't work on translations that aren't provided to users. That data structure currently lives as a python dict, so I could have the platform provide it as a JSON, CSV, or something similar. Other than ironing this detail out, I think we're about ready to go.

Looks like our actual supported language count is 83. I was doing quick glances before and was apparently including keys and values in the count. Here's the json whitelist which is computed from the live site. https://wikipedialibrary.wmflabs.org/i18n-whitelist

OPEN This issue is open, waiting for action

Hello, Pywikibot:Category-changing was merged into Pywikibot:Category-replacing in Pywikibot's code. How the merging process goes here? Could missing or red in the latter one be refined by the ones from the merged one?

We don't do merges. It requires knowledge of all the languages.

If you think you have sufficient knowledge of all the affected languages, you can add (effectively new) translations by editing JSON files in the repository.

Already done, thank you

CLOSED This issue is closed by Candalua

Hello. On the ProofreadPage extension I submitted a change to create 5 new system messages, named "MediaWiki:Proofreadpage qualityX summary" where X = 0, 1, 2, 3, 4. The meaning of these new messages is similar to the old "MediaWiki:Proofreadpage qualityX category" messages, so most sites will want to reuse the same message, however some languages need a separate message so they can provide a better translation.

Before we release that change, is it possibile to mass-copy the old "category" messages into the new "summary" messages? And, can the new messages be marked as being "in need of review", so that translators will notice them and change them if needed?

Example: MediaWiki:Proofreadpage quality1 category/it should be copied on MediaWiki:Proofreadpage quality1 summary/it.

Thank you very much.

If the new messages have a different meaning, we don't generally move the old translations. You can copy the existing translations directly in the code. Traditionally people add "!FUZZY!" at the beginning of the text to indicate that the translations should be reviewed.

The request was not to move, but to copy. Anyway, by now these new messages have already been translated in most languages, so I guess my request can be quietly dropped.

OPEN This issue is open, waiting for action

What can we do to avoid requests for this language?

I think we should recruit a Russian speaker to vet all Russian translators (and follow their activities after approval in case one gets through). I don't want to disable sign-ups for that language completely. How bad is the situation right now?

Just now the situation is quiet, but this can mean nothing.

What about now?

I think he's present not anymore.

OPEN This issue is open, waiting for action by Nemo_bis

Is it possible designate proofreaders for a particular project, such that specific users must accept translations before they get pushed to github? I can't seem to find functionality like this, and I imagine it might be antithetical to translatewiki's principles, but I figured I'd ask.

Also, is it possible to exclude particular locales for a project? Let's say my project wanted translations for any given locale *except* es-MX.

It's possible to add, map or blacklist locales for specific projects. We don't generally add country-specific locales like es-MX or it-IT.

Translate provides quality assurance features including a translation review. It was initially restricted to a select group of editors but in the end there was no use for the distinction and now all translators are automatically allowed to review each other's translations. Usually, any disagreement is quickly resolved simply by explaining your reasons: on a wiki it's easy to determine who did what and to contact them.

So our suggestion is to give it a try and avoid overthinking things beforehand. Solutions can be found if any real problem arises, but for now an approval system is a solution in search of a problem.

Nemo said it well. I would like to add that there are some cleanups on going which language tags are enabled generally and which are not.

Thanks! Can you link to the page where I can blacklist a locale for a specific project? I help manage iNaturalist.

Regarding approval, the problem is that we have country-specific portals into our platform with groups that manage them, and sometimes those groups want approval control over translations to ensure their users see consistent use of language on their portals, and they get frustrated when they translate a string one way and some other translatewiki user comes along and changes it. They don't want to have to engage in the kind of constant negotiation process you're suggesting, they just want to translate it once and lock it down. For example, I think our Mexican partners have had to re-translate switches from "Tú" to "Usted" numerous times and they're tired of it. From what you're saying, it sounds like locking things down is impossible on translatewiki, which is fine, but I just wanted to describe the problem such a feature would solve. Whether or not it is a problem is pretty subjective, but from the perspective of these particular people, it is a problem.