Support

The pull request has been merged now, so it will appear here next time the source messages are imported.

[bug] Translate UI - wrong placement of circled accelerator keys

Accelerator keys in circles displayed in the Translation UI are incorrectly placed. They should not collide with the editable text area where they obscure the text being edited. Ideally they should be placed just below the bottom of their border box, with enough margins, and not above the top border.

And the surrounding circles (actually boxes with large paddings and rounded corners) are too large, given they are also completely opaque: there's no need to have so large paddings.

Finally they should probably be visible only if the input focus is inside the text area, and probably only when we hold the [Alt] or [Super] key (depending on the browser's UI for its platform) to use them by pressing the displayed key (one digit or letter). Without this focus (flashing caret or current text selection) in the editable text area, the accelerator keys should have no effect and should then not be displayed at all. In fact most users will prefer clicking (or tapping on a tactile screen) the suggestion boxes to insert their suggested text into the text area at its current input position.

Now if you zoom in/out with the browser their placement is even worse. They are in fact absolutely positioned in the window instead of being relatively positioned, and their computed absolute position is completely wrong.

Verdy p (talk)‎

They are only visible when one presses ALT. Sometimes they get stuck if we don't key keup event (such as when ALT+Tabbing to another window), but pressing ALT again will make them go away.

Nike (talk)‎

No, they are permanently on screen... Pressing ALT or releasing it does not change the display. This was probably displayed on just a few browsers, but does not work in Google Chrome (the most widely used browser in the world) in Windows (though I don't think this behavior is just tied to Windows).

I found that the bug occurs sometimes after pressing ALT+TAB to switch to another application in Windows, and then returning to Chrome, also with ALT+TAB or with a click. The release event for ALT key is no longer detected, even when pressing and releasing ALT again, or it has no effect for objects already in the interface. Note that there are still multiple warnings displayed in the Developer console, including deprecated interfaces in several component libraries, related to jQuery unsafe/deprecated APIs ,or APIs in Mediawiki itself when they hook some event handlers; may be the same handler has been registered twice or registered in a "lazy" way, possibly the ALT release event is registered too late and not bound correctly in all closures, or this does not work with international keyboards (if the Alt key is confused with AltGr; it may also be incorrect detection of Chrome for Mac keyboards when we use Windows).

I've not seen such issues in other websites using jQuery, where we can safely use common Windows accelerators like ALT+TAB to switch between multiple open windows. And I have a very minimalist number of browser extensions (I have even disabled several extensions preinstalled by Google in Chrome for Windows, and not allowed Microsoft to install its own extensions into Chrome).

There's no such issue if I use Edge Beta (Chromium-based), which is using dramatically less memory than Chrome and is more power-efficient, and loads faster, I'm about to switch to Edge Beta if Microsoft ever releases it instead of its current home-brewed Edge which is an horror breaking many sites.

And anyway the fact that their position is very wrong and is even worse with browser zooming (where circles are going to higher positions when the text and boxes are shifted down when the zoom lever is larger) is a sign that jQuery or similar APIs are wrong, or make unsafe assumption.

Verdy p (talk)‎

[critical bug] MediaWiki:Withoutinterwiki-legend/fr : translation mixups: updates are going to the wrong page

Translations are sent to the wrong page. Trying to set them correctly, the submission is accepted, but when we refresh the page, we still see an unrelated message, not for this resource, and no change is applied (and no error ever displayed).

And if we look deeper, we see that what was submitted has in fact changed another page, creating a mixup, which then affects multiple other pages.

Very probably problem of index corruption (page or version ID's) in the database (I think there are duplicate ID's in some tables that should be unique), or a previous bad use by some prvilege admin of native SQL update.

As well the histories are mixed up across pages.

A maintenance should be performed to check the database integrity (notably check all table indexes).

It is also likely a problem of the background job queue, which seems to be stalled (recent changes are not fed correctly, statistics are out of sync, page counts are wrong...)n or its backlog of pending jobs is too large, or there's a lack of storage on the server.

Verdy p (talk)‎

I just opened the page MediaWiki:Withoutinterwiki-legend/fr and it really shows the unrelated text, but clicking on "Edit" shows the text correctly.

Vlad5250 (talk)‎

This was a real bug (https://phabricator.wikimedia.org/T235188) and is what is referenced by the site notice at top. It was affecting transwlatewiki.net stince the beginning of month. The bug was a caching bug on the server. Still it affects some resources displaying incorrect "fuzzy" state (yellow icon) which seem to reoccur again. The issue was real and very strange. Its resolution is partial, as some other glitches are still occuring; the resolution seems to be non definitive because the impact is still not well understood. That's why the site notice at top remains.

Verdy p (talk)‎

Quite certain that these issues started appearing since our deployment last Wednesday (8th Oct, 2019). We should not be seeing this issue on twn any more, but if you do, please ping on the Phab ticket or here.

Regards,

https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-wikieditor&language=gom-latn&filter=&action=translate

Cannot save translations due to editinterface right

Thread summary:[Link to] [Edit]

? This issue is unconfirmed, still to be investigated

I am localising the group 'Wiki Editor' into Konkani:

It seems that 71 out of the 186 messages require the editinterface right. How can I enter these translations? Could I request for the editinterface right, at least on a temporary basis, or is there someplace where I save the translations to be entered by someone else?

https://translatewiki.net/w/i.php?title=MediaWiki:Wikieditor-toolbar-help-heading-description/gom-latn&action=edit

You already have the 'editinterface' right which is assigned to the 'translator' usergroup. However, I notice that some messages are recognized by the software as having JavaScript content model and require the 'editsitejs' right, which is assigned to the 'interface-admin' usergroup. Maybe it's your situation?

Vlad5250 (talk)‎

For example, if I try to save this message:

I receive the following error message: "Saving the translation failed: You do not have permission to edit this JavaScript page because it may affect all visitors. Permissions for editing of sitewide CSS/JS/JSON files were recently separated from the "editinterface" right. If you do not understand why you are getting this error, see mw:MediaWiki_1.32/interface-admin."

https://github.com/mantisbt/mantisbt/pull/1564#issuecomment-533840363

An Error in https://translatewiki.net/w/i.php?title=Phabricator:phabricator-uiexample-80d8b8cf2291a90b/en

When I am trying to translate that in Turkish, the error gives...

Failed to save translation: This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: Protect sensitive pages #2

Are you guys going to fix it?

BaRaN6161 TURK (talk)‎

Thanks for reporting. This abusefilter rule is only a workaround. The actual solution is to mark this message as "ignored", because it does not need to be translated.

Nemo (talk)‎

Okay.

BaRaN6161 TURK (talk)‎

Deleting unused strings from translated language files

Thread summary:[Link to] [Edit]

CLOSED This issue is closed by Abijeet Patro

Hi guys,

I'm posting this here since you don't seem to be responding to @translatewiki mentions in GitHub pull requests...

The question is, is it OK to directly modify foreign language files (translated and committed by translatewiki) ? Would that have an impact or cause problems, and if so, what ?

Specifically, this relates to the following commits in the above-mentioned PR:

Cheers

-- Damien‎

If you delete the English strings (the source strings), the next export will take care of deleting the translations as well. As for changing translations, it's better to do it here on translatewiki.net, because then the translators can see what you're doing and why.

Nemo (talk)‎

Thanks for your reply.

Please note that the actual translations have not been modified at all. Changes to foreign language files are :

removed unused strings ==> From your reply, I understand is that by deleting the string myself, I'm only anticipating on what translatewiki.net would do anyway, so that should not cause any issue. Is that right ?
moving strings around in the file (without changing anything) ==> I assume this has no impact, can you confirm ? (note, this was done to have consistent ordering of strings across all language files)
renaming a language string (i.e. not the translation itself, but the string's identifier) ==> this is the one I'm really not sure about. I would think yes based on what the FAQ says, but since it also mentions informing the staff...

-- Damien‎

Hi Damien,

removed unused strings --> This should be fine but would recommend doing it only for the source language and not the foreign language files.
moving strings around in the file --> Again no issues here and should be fine.
renaming a language string --> This is also fine. Thanks for the ping regarding this. We will review and do the necessary renaming on our end, which is quite easy.

Regards,

Hello Abijeet,

FYI the pull request https://github.com/mantisbt/mantisbt/pull/1564 has been merged a few minutes ago, feel free to do your magic at your next convenience.

Cheers, Damien

-- Damien‎

Hi Damien,

This is done. Translatwiki now has and tracks the renamed language keys.

Regards,

Mobile version of main page

I would like to know to set-up a mobile version of the main page on nds-nl.wiki. Currently it shows the whole main page, but I would like it to only display certain paragraphs. Any help would be very much appreciated (main page).

Servien (talk)‎

I am afraid this is not the right place to ask for such help. Hopefully someone will post a reply pointing you to the right direction, as I don't know whether his is related to Mobile Frontend or something that can be done in the wiki itself.

Nike (talk)‎

Saving the translation failed

I was trying to modify two pages content but I was prevented:

MediaWiki:Mainpage/ary from {صفحة لولا} to {الصفحة الرئيسية}; I was prevented for the fllowing reason: Established main page translations cannot be changed directly as it would disrupt wikis using the old translation.
the outdated translation of MediaWiki:Copyright/ary because I don't have the Permissions for editing of sitewide CSS/JS/JSON files.

What can I do to fix the above translations?

SADIQUI (talk)‎

You can't modify MediaWiki:Mainpage/ary because AbuseFilter 3 prevents edits from you, simply request changes on here (like you already did, so just wait until someone with the needed rights does this)
Similar to above, simply wait until someone with the needed rights does your request action.

Tobi 406 (talk)‎

Request username change

Thread summary:[Link to] [Edit]

CLOSED This issue is closed by Jon Harald Søby

Rename my account from "A2093064" to "Xiplus". Thanks.

A2093064 (talk)‎

Done

MediaWiki:Leafletdraw-edit-toolbar-buttons-edit/en

Thread summary:[Link to] [Edit]

CLOSED This issue is closed

gerrit:539878

It suggests that you can edit (or delete) layers, but really the corresponding button in VisualEditor's map dialog currently allows editing all geometric features present and there are no layers to edit. A layer in sense of managing geometric features is usually a group of features.

Pikne‎

Tools for counting users' contributions for bbc-latn

Thread summary:[Link to] [Edit]

CLOSED This issue is closed by nemo_bis

reopen if more is needed

Hi Nike, is there any edit count tools in translatewiki.net for us to know any/all users' contributions for bbc-latn? Our group in Jakarta has been translating in that language, and we plan to give small prize for some of the most active users. Thanks.

Naval Scene (talk)‎

Hello, I think Special:SupportedLanguages is the only way to do that, currently. By creating Portal:Bbc-latn/translators I managed to make the language appear on the page; you should try fetching the usernames from recent changes and/or Category:User bbc, add them to the subpage and see if counts are generated.

Nemo (talk)‎

Naval Scene, I saw you added some names, did you find what you needed?

Nemo (talk)‎

Two of the names are struck through. I have opened a separate thread to get the whole list reviewed.

Lloffiwr (talk)‎

Nemo & Lloffiwr, so sorry I forgot to reply. The May 2013 bbc-latn people/community interest turned out to be just a short one. So we didn't give any prize and will not be doing bbc, until we could find another bbc group that's willing to do this. Thanks.

Naval Scene (talk)‎

Moroccan arabic ISO639-ary

Hello, I speak Moroccan Arabic (Darija), & I noticed big mistakes (not talking about translations) about Darija "Moroccan Arabic" ISO639-ary, I'll propose here some modifications:

The Language name in its own language: {الدارجة} instead of {Maġribi}

ref1 see section "Autonym", {الدارجة} read as [ddæɾiʒæ] means common language

Writing system & direction (rtl/ltr):

It is writed with Arabic script as it's a member of the macrolanguage Arabic ref1 (section Writing) & ref2, then the writing direction is rtl (right to left), see for example a news website written with darija: www.goud.ma

SADIQUI (talk)‎

For this site only, there are more languages than those currently supported in Mediawiki; as the purpose of thios site is to help develop the translations, including in languages still not in Mediawiki, there's the Template:Languagename that provides local translations (notably when they are still not supported by the "#language:" parser function of Mediawiki which uses a very partial database with many missing data, or approximative data that have not evolved since years and were refined in relevant standards (notably in ISO 639, with most data vetted from The Linguist List and researches indexed in Glottolog, frequently many years before they are vetted in ISO 639, then incoporated to the IANA database for BCP47 and then vetted once a year in CLDR (which is also very incomplete except a for few major languages), and finally integrated in MediaWiki (where there are also various non standard uses kept and not corrected since many years, sometimes decennials).

The Template:Languagename however allows an immediate central change locally for use in portals, languages navboxes, without having to rewrite many pages. It can be discussed here. But note that Wikipedia is not the best source (even its English version) because various distinguised languages are merged. Other possible sources include Wikidata. Both these wikis still want to provide sources. This Translatewiki.net just attempts to cover the most recommended practices, backed by serious linguistic sources (academic) like Glottolog and The Linguist List, then BCP 47 (for variants and current best practices that preserves the upward compatiblity) then by ISO 639 (for the encoding and English-only names, but ISO 639 still does not have enough coverage, even for modern languages and provides no hints for their classification like the one made in Glottolog, and ISO 639 has not always been not very stable), then CLDR (for translations of language names to other non-English languages or for autonyms), then Wikipedia (English Wikipedia is not always the best source even if it has the widest coverage and it's a very instable source).

Sometimes some existing Wikipedia editions use the wrong codes, still kept for legacy reasons, but do not distinguish them as much as they could (or currently don't have the tools to allow useful distinctions). Here we won't focus on the existing decisions made locally in a single wiki, because Translatewiki.net is for all wikis, and projects (including those outside Wikimedia itself).

Verdy p (talk)‎

A language label

How to modify a language label? for ex: "English", "Kotava", " Patois"

SADIQUI (talk)‎

You mean on Special:Preferences? As far as I know these are determinated by the software and not changeable.

See here the qqx version

.

Tobi 406 (talk)‎

For this site only, there are more languages than those currently supported in Mediawiki; as the purpose of thios site is to help develop the translations, including in languages still not in Mediawiki, there's the Template:Languagename that provides local translations (notably when they are still not supported by the "#language:" parser function of Mediawiki which uses a very partial database with many missing data, or approximative data that have not evolved since years and were refined in relevant standards (notably in ISO 639, with most data vetted from The Linguist List and researches indexed in Glottolog, frequently many years before they are vetted in ISO 639, then incoporated to the IANA database for BCP47 and then vetted once a year in CLDR (which is also very incomplete except a for few major languages), and finally integrated in MediaWiki (where there are also various non standard uses kept and not corrected since many years, sometimes decennials).

The Template:Languagename however allows an immediate central change locally for use in portals, languages navboxes, without having to rewrite many pages. It can be discussed here. But note that Wikipedia is not the best source (even its English version) because various distinguised languages are merged. Other possible sources include Wikidata. Both these wikis still want to provide sources. This Translatewiki.net just attempts to cover the most recommended practices, backed by serious linguistic sources (academic) like Glottolog and The Linguist List, then BCP 47 (for variants and current best practices that preserves the upward compatiblity) then by ISO 639 (for the encoding and English-only names, but ISO 639 still does not have enough coverage, even for modern languages and provides no hints for their classification like the one made in Glottolog, and ISO 639 has not always been not very stable), then CLDR (for translations of language names to other non-English languages or for autonyms), then Wikipedia (English Wikipedia is not always the best source even if it has the widest coverage and it's a very instable source).

Sometimes some existing Wikipedia editions use the wrong codes, still kept for legacy reasons, but do not distinguish them as much as they could (or currently don't have the tools to allow useful distinctions). Here we won't focus on the existing decisions made locally in a single wiki, because Translatewiki.net is for all wikis, and projects (including those outside Wikimedia itself).

Verdy p (talk)‎

About Wikimedia:Wikipedia-ios-talk-page-discussion-read-ipa-accessibility-attribute/zh-hant and Wikimedia:Wikipedia-ios-talk-page-discussion-unread-ipa-accessibility-attribute/zh-hant

Hi allǃ

This is incorrectly translated. I don't speak the language so I can't reliably translate it but it's definitely not the English "rɛd". The same applies to Wikimedia:Wikipedia-ios-talk-page-discussion-unread-ipa-accessibility-attribute/zh-hant.

Nharateh (talk)‎

Thanks for reporting this. I've marked these two translations as outdated.

Thank you!

Nharateh (talk)‎

iNaturalist Leaving Translatewiki

Thread summary:[Link to] [Edit]

CLOSED This issue is closed by Abijeet

Hi folks,

We at iNaturalist are extremely grateful for all the translations we've received from Translatewiki over the years, but we would like to stop using Translatewiki for translations as of October 1, 2019. We want to make sure all Translatewiki translators continue to receive attribution, so any advice / requirements on how best to do that would be appreciated. We could make a wiki page in our github repo, or maybe attribute them by name in our README or on our website. In doing so we will also make sure to thank Translatewiki itself for many years worth of translations.

If possible, we would like iNaturalist's presence on Translatewiki to be removed by the above date so translators don't waste their time providing translations that will never be integrated into our code.

If there are any requests or requirements you have regarding the end of our collaboration, please let me know.

Kueda (talk)‎

Thank you for caring about not wasting translators' work. Naturally, we'll do as the project pleases.

However, could you please elaborate on what are the reasons for this decision? I suspect they might be easier to fix than you think.

I see a lot of strange things going on at https://github.com/inaturalist/inaturalist/commits/master/config/locales , probably a result of some misunderstanding. If the things are not going well for iNaturalist, maybe a solution is to try a simpler and more efficient workflow compared to what we had so far. For instance, normally we strongly advise against: 1) pushing outside master, which makes errors more likely and slower to fix; 2) keeping up parallel/competing workflows and translation systems, such as Crowdin and translation changes directly pushed to the repository.

Nemo (talk)‎

Hi Nemo. The two main reasons are the Mediawiki UI and Translatewiki's, well, wiki-esque policies.

Regarding the UI, we on iNat's staff find Translatewiki so frustrating and awkward to use that we hardly ever interact with translators directly and are extremely demotivated to fix things like problems with markup code in translations. We want to have a closer relationship with translators so we can explain things like context, jargon, why markup needs to be copied exactly, etc. I realize this is possible on Mediawiki, but those of on staff find it difficult. Furthermore, a great deal of our growth beyond English-speaking countries gets mitigated by partners in those countries, and those partners tend not to be technically-minded and often have even more frustrations with the Mediawiki UI than we do. I realize Translatewiki could probably fix things like those markup issues (and you have fixed many of them, both through filters and manually, so thanks for that), but it seems unlikely that a) you will abandon Mediawiki for a more usable web application, or b) that Mediawiki will become more generally usable in the near future.

Regarding policy, we really need to allow some people to have privileged approval permissions within specific locales. This is such a deal-breaker for some of our international partners that they simply refuse to use Translatewiki and asked us to stop integrating Translatewiki's contributions for their locale. Given my past inquiry on this topic, I got the impression that this kind of hierarchy is something that Translatewiki is philosophically opposed to. Personally, I understand and to a large extent agree with that stance, but it's proving to be a real hindrance to some of our collaborations.

Since we don't think either of those issues are likely to be resolved any time soon, we're going to move our translation process to Crowdin, which we've been using for our mobile apps for years and, while it has its own set of problems, does not have the problems I described above.

I hope that all makes sense and that my explanation didn't seem overly harsh. Again, we've been very happy with the translations we've received from Translatewiki and I've personally always been impressed with how responsive the Translatewiki developers have been considering it's an all-volunteer open source project.

Kueda (talk)‎

Well, I'm surprised because at https://forum.inaturalist.org/t/translators-what-do-you-like-dislike-about-crowdin-and-translatewiki/3108 I don't see anyone complain about this perceived problem. If people had experienced such big conflicts within their locales, I would expect to see signs of it somewhere. Could it be that some translators just refused to engage because they rejected the wiki way for ideological reasons?

Nemo (talk)‎

It's possible some folks have ideological problems with wikis, but the complaints we've heard offline about assigning proofreaders are more practical, e.g. the ones I tried to describe at https://translatewiki.net/wiki/Thread:Support/designated_proofreaders,_excluding_locales.

Kueda (talk)‎

I understand, but as I said "our suggestion is to give it a try and avoid overthinking things beforehand". If people were making changes like Tú vs. Usted outside translatewiki.net, i.e. without communicating with other translators, that's not a problem with the platform but a social problem. I don't see anything on translating:iNaturalist warning translators to use "Usted", for instance.

Another example: at times your commits resulted in User:FuzzyBot seemingly edit warring with users [1] [2] who appear to have registered just to translate iNaturalist (so iNaturalist translators?). No wonder it was hard for the es-mx locale to coordinate, when translation edits were flying in all directions unexplained.

This social problem of lack of communication can be nudged towards a fix by eliminating the alternative platforms and forcing everyone to translate on translatewiki.net. Translators would then discover that we offer tools to quickly solve such issues of consistency, like Special:SearchTranslations, as well as effective communication methods like edit summaries, talk pages and so on.

It seems to me that you've not yet really tried to use translatewiki.net, so it's no surprise that the results have been unsatisfactory. I would suggest to give it a try for real, for instance with a trial of 3-6 months. If the communication/coordination problems continue to be so pressing, then they can be acted on (as opposed to letting them stew for 18 months or so without any sign to the community of translators).

Nemo (talk)‎

Show 2 replies

Hi Kueda,

We've run exports from Translatewiki.net for iNaturalist today, and then removed the project from the list of supported projects. Translators will no longer be able to translate messages on the project, and no exports will be made from Translatewiki.net to the iNaturalist Github repo.

You can remove the access given to @translatewiki Github account

Best of luck for the future.

Regards,

[I understand, but as I said "our suggestion is to give it a try and avoid overthinking things beforehand". If people were making changes like Tú vs. Usted outside translatewiki.net, i.e. without communicating with other translators, that's not a problem with the platform but a social problem. I don't see anything on translating:iNaturalist warning translators to use "Usted", for instance.]

An issue which is also the case with German and Dutch. I ignored it cause changing it is too much work, although Google translate defaults to using Usted...

Optilete (talk)‎

Delete empty qqq pages

Thread summary:[Link to] [Edit]

CLOSED This issue is closed by Jon Harald Søby

Some time ago I created qqq pages (switched namespace to qqq and started translating without going back to de), that are now empty (I cleared them).

As I think having empty pages is not good in general, I'm asking for the deletion of these pages.

The pages are:

Tobi 406 (talk)‎

The /qqq pages are intended to provide help to translators, such as listing other resources with similar terms, giving hint about usage (when the English resource alone is ambiguous, such as lack of distinction between nouns and verbs, or the too frequent overuse of Capitalization in English where other languages have more restrictions, based on meaning or usage in sentences). They may convey pointers to check the usage in the application, or with related separately separated resources, or give hints about what will be in replaced placeholders. There may also be warnings, such as terms probably left untranslated (except if needed for transliteration of the Latin script, notably brand names that are still derivable grammatically in some languages; some brands may also have dedicated adaptations for some languages, e.g. "Wikipedia", with the adapted name chosen in a separate process that may need to be documented in qqq pages). So the /qqq pages are not specific to any language, they are usually written in English (sometimes they include some autotranslated templates for generic hints). For some projects, there may exist a terminologic list that should be checked (to help increase the coherency). But they have nothing to do with specific languages like "de"... The "/qqq" pages are helpful and can be recreated at any time even if some hints are removed (because they were temporary). If you are multilingual or can read/understand other languages, check how resources are translated, because you can detect cases that were tested and corrected in other languages and this gives hints about what to do (English alone is ferquently not enough). If there are talks somewhere about terminologic choices, these "/qqq" pages should not be cleared. If a problem was found in a language, and then fixed for that language, it's likely a problem also in other languages and keeping the issue doucmented is helpful. It also provides feedback to developers (even if they often request to post a bug report in a bug tracker like Phabricator or in the Support request pages: post the link to the bug report and its talks and resolution, keep it even if it's resolved). Deleting a page will just make the history invisible, and if it is recreated, the history is lost. An empty page anyway does not cost anything more in the server. Translatewiki.net otherwise is not a development platform for the supported software to translate. That's the role of "/qqq" pages to post any such reports and hints that will help translators to other languages still lacking proper translation: this avoids long searches and repeated corrections later after testing the result (which will not be used immediately but integrated progressively).

But NEVER use the "/qqq" page for making any actual translation, these are not junk "test' pages, but are like what documentation pages are for templates.

Verdy p (talk)‎

Done Deleted all but two where other users have added content in the meantime.

MediaWiki:Copyright/gom-deva

Protected edit request

Thread summary:[Link to] [Edit]

CLOSED This issue is closed by Abijeet Patro

Please enter the translation for the following message. I do not have permission to edit it.

मजकूर $1 हाच्या खाला उपलब्ध आसा खेरीज हेर नोंदी केल्या शिवाय.

https://mr.wikipedia.org/wiki/दुसरे_महायुद्ध

Messages in the "Mediawiki:" namespace are not editable except by admins. You have to locate the messages in the translatable space, where they can be vetted and will later be imported into the "Mediawiki:" namespace by authorized bots. Also you use a final dot in the sentence, instead of the danda standard...

Verdy p (talk)‎

In the past I have put requests in the support page for such translations, and admins have entered it for me. For example: here. Nevertheless, please let me know where I can save the message for vetting.

Regarding the final dot, you must be aware that unlike Hindi, in languages like Marathi and Konkani, it is usual to use a dot for the end of a sentence and not a danda. Take a look at some articles in these languages, and you will see that the danda is not used, e.g.:

https://gom.wikipedia.org/wiki/उदक

Nike or Nemo bis, please could you help save this message? I do not have permissions because it involves CSS/JS/JSON .

Done, thank you for your contribution.

Regards,

Thank you :)