Support

From translatewiki.net
Jump to navigation Jump to search
NoteProblems? Questions? Suggestions? Write your message below. – See also the FAQ or try to catch us in IRC.

Your request has been forgotten? It's suggested to use {{Support}} in thread summaries, see also documentation.


Contents

Thread titleRepliesLast modified
Add Covid Ratio514:51, 23 November 2020
[Wp/trv]Translation of MediaWiki (most important messages)421:08, 22 November 2020
Support Saraiki language621:06, 22 November 2020
Courtesy vanish me109:51, 21 November 2020
Translatewiki.net does not have a mobile view (MobileFrontend and MinervaNeue)014:02, 20 November 2020
[kcg] New Language Addition (Tyap / Katab, A̠lyem Tyap)009:06, 20 November 2020
Language name correction (Southern Luri/luz)116:35, 18 November 2020
Grammar215:33, 18 November 2020
Minor web site enhancements412:22, 13 November 2020
MediaWiki:Notification-bs-pageassignments-user-group-add-summary215:41, 12 November 2020
Translations by ChoiChong009:15, 9 November 2020
Delete MediaWiki:Dberr-info/hif-latn208:18, 9 November 2020
RC Wikidata207:44, 28 October 2020
Error on MediaWiki:Wmobile-copyright/en323:24, 26 October 2020
attribution options?019:24, 26 October 2020
Error on Wikimedia:Citationhunt-instructions details/zh-hans018:35, 26 October 2020
Obsuser and his translations216:15, 25 October 2020
Transadmin013:46, 24 October 2020
[Sxr] [Xnb] Translation of MediaWiki interface is not supported by translatewiki.net207:37, 24 October 2020
Start Hanja Script language for Korean1617:09, 23 October 2020
First page
First page
Previous page
Previous page
Last page
Last page

Add Covid Ratio

Could you please add Covid Ratio (source) to translatewiki? Thanks!

David (talk)22:11, 22 November 2020
Edited by 2 users.
Last edit: 07:47, 23 November 2020

Do you manage this site ? Anyway it is focusing only US with few statistics per county. I don't think it's worth the value compared to international sites (including Wikipedia that follows lot of statistics).

And there's not a lot to translate: the country names ? They are in Wikidata. The rest is jsut a few messages. If the site author wants to make it a long term project for statistics independantly of country and division levels, may be, but the UI is too much in alpha stage and limited in scope. May be that site would want a few translations for other languages of US.

Such site is only useful if it tracks accurate data sources with regular updates and sources, but for now there's not even any indication of sources, so I would better trust official sites: WHO... or even Google (which in fact just uses and participates to the statistics project on Wikipedia/Wikidata for this topic, as this is a good place to collect and keep lot of sources and organize them...). and there are now tons of other websites for local statistics in each country, and for various platforms (web or mobile).

Verdy p (talk)23:44, 22 November 2020

Yes I maintain the site. I'm totally open to adding more states/locales, but I do not have the time to go through each state's data source. As I mentioned in the footer the data comes directly from the Florida Department of Health, there isn't a more official source for county-level data than that. If any other developers would like to add other locals, please submit a PR on the GitHub repo. If you know of an API that gives out county-level data for the entire country, I would love to use that instead. :)

David (talk)00:32, 23 November 2020

Oh... I did not even see this was even more limited to Florida only! Really, you should first ask for help on English Wikipeia at least to see if you get support for extending it to other US states, and possibly other countries. But I bet most won't be interested as Wikipedia already has a more complete dataset (and accurately checked, with all sources compared, not just one which uses one state-level method, and not the exclusive one at federal or international level). You should know that such statistics is highly sensitive to the methodology used, and there are many criterias (the WHO site gives some hints about their varaibility and what they are about, there's no single way to count things, including in one given country, and governmental sources are not always accurate on everything, frequently with underestimates!)

Such project is in fact not maintainable by a single person from his chair at home, it absolutely requires huge cooperation, at nation and international scale and requires monitoring as well other indicators. Even Google renounced to do that itself ! The best you can do however is to help the Wikipedia project if they are missing some data sources, in order to collect and track more (you MUST absolutely give the sources, as many sources use different methods or may be out of sync with others, using different time-frames for their measurements, and also frequently correcting their figures later).

Then you can use the data collected in Wikipedia and Wikidata to make a translatable app if you wish (exactly what Google did itself!).

Verdy p (talk)14:23, 23 November 2020

English Wikipedia, nor Wikidata, maintain county-level data which is necessary to preform the calculation.

I'm not sure why I have to defend an applicaiton I wrote. If you don't want to translate the 7 strings, then just say so.

David (talk)14:44, 23 November 2020
 

Even if I were to expand the data set (which I have yet to find a suitable one), the UI would still need those strings translated.

David (talk)14:51, 23 November 2020
 
 
 
 

[Wp/trv]Translation of MediaWiki (most important messages)

Edited by another user.
Last edit: 07:37, 20 November 2020

Hello, we want to translate the content (Wp/trv) of MediaWiki (most important messages).One of the sentences (Content is available under $1 unless otherwise noted.) is not allowed us to publish our translation. And the reason is you do not have permission to edit this page because it contains raw HTML which can be modified to affect all visitors.We would like to know how can we solve this problem?

Mecytan (talk)03:50, 20 November 2020

This is not strictly for Mediawiki as what you wanted is to translate the Wikipedia Incubator for Portal:Trv (Taroko, Seediq): the UI of the wiki effectively comes for Mediawiki (so the Incubator wiki itself does not allow modifying it locally), but this could have happened for other projects as well. You have two solutions:

  • contact a local wiki adminsitrator to make a change for you (it will be kept specifically on that wiki by adding another level of protection that will block reimports from Translatewiki.net, where it may be translated differently in a more generic version not specific to Wikimedia).
  • or find the relevant message on this Translatewiki: if you can't edit it here, then propose the translation to this Support, and an admin will submit it for you: please link the message

I've try to locate it, and found 4 resources (here in English, two for MediaWiki itself (they must be generic):

and two for Wikimedia-specific contents:

Note that the reason given ("raw HTML") is not relevant as there's no raw HTML in fact. But that protection was required for legal reasons, because these messages are required on many pages (for legal reasons) and they must not be altered without careful check and approval by site admins.

So you have to give the translated text to put into

Verdy p (talk)07:43, 20 November 2020
 

@Mecytan: If you want to add the translations here in translatewiki please post your translations here. I will add them for you.

Raymond09:50, 21 November 2020

@Raymond: Thanks for your help. The translation is "Rahuq nan ii o niqan kingal duri pgkla, aji saw kiya do ruwan ruwahan patas dmuuy kana $1 gaya mgay biyax kklawa." Please help us to add the content.

Mecytan (talk)13:15, 21 November 2020

I have created MediaWiki:Copyright/trv for you. Please check the content. If you need further help please add the message name and the translation here.

Raymond17:47, 21 November 2020
 
 
 

Support Saraiki language

Edited by author.
Last edit: 10:04, 16 October 2017

Language Saraiki is mainly written in Arabic script. So Skr and Skr-arab be merged. In wikimedia and other sites Skr-arab be deleted. Because Saraiki is just one language. In interface language and internationalization only one langauge be shown. Interface of Urdu words be adjusted as they are adjusted in SKR_Arab. All translations be converted to Skr i.e., Skr-arab be renamed as skr. so that one language Skr-arab be deleted from Special:SupportedLanguages. In language selector of Wikimedia Saraiki is Written two times. Kindly Skr-arab be deleted.

Saraiki (talk)15:33, 27 July 2017

Merging messages between two variants can be easy for sysops by using Special:mergehistory, but I'd love to know what's your actual wanted code (aka merge which to which)? Merge skr to skr-arab? Or vice versa?

Liuxinyu970226 (talk)00:57, 1 August 2017
Edited by author.
Last edit: 12:34, 28 September 2017

In interface language merge Skr-Arab in Skr، In interface language the all work as stood as in Skr-Arab be adjusted as Skr, and the word Skr-Arab be deleted in the the internationalization of the the language. Wiki is only in Skr. Please this conflict be removed. Saraiki. (talk) 10:45, 1 August 2017 (UTC).

Saraiki (talk)10:45, 1 August 2017
 

Sorry, for technical it will be too complicated to do this. However, it doesn't matter because the "skr-arab" code will remain internal, and you'll see "skr" in the actual sites.

Amir E. Aharoni (talk)16:42, 12 November 2020

In summary we jsut want to make sure that [skr] is an alias for [skr-Arab] by default, just like [zh] is in alias for [cmn], or [en] is an alias for [en-Latn].

Like for all aliases, they are to be treated equivalently, except for the purpose of fallbacks with BCP47 rules, where the extra script code can be used as a guide to select one of several possible languages using the same script. This does not mean we create duplicate data for localization, but that where data is missing, fallbacks will resolve differently for languages that may have different scripts, even if one of them is the current standard or the most frequently used.

  • e.g., English is not written only with the Latin script, it may still be written with Deseret, so [en-Dsrt] is still a distinct variant, but if it's missing it will fallback to [en]
  • for Serbian, the Cyrillic script is the default so [sr] can be aliased to [sr-Cyrl] (or [sr-ec] only in Wikimedia wikis which violates the BCP47 standard here) and we don't need to have the two datasets for [sr] and [sr-Cyrl] (they should be identical), but we can still have [sr-Latn] which fallbacks to [sr] (and thus, also to [sr-Cyrl] because it is equivalent by its alias), however it can also fallback first to [sh-Latn] which will itself fallback to [hr-Latn]).

We can consider that for fallbacks, preserving the script is preferable to preserving the base language; so the two aliased codes are not completely equivalent: they are only equivalent in translation datasets, but not in applications that will use them with their own fallback chains to decide the order of resolutions.

If no fallback is needed (because a translated resource is found in any one of the two aliased datasets, which are in fact just the same one), using one code or the other does not matter. So in this TWN wiki, nothing needs to be changed except making sure that there's only one dataset open, the other being locked, or "redirected" to the other code.

So I would recommend keeping [skr-Arab] here, and keep [skr] closed/locked, with a possible redict. On the [skr] portal, we can display the shorter code, but as well all variants including [skr-Arab] as the default variant. The short code will be locked, all translations will be made in the unambiguous [skr-Arab], except if another script is used, like [skr-Cyrl].

Verdy p (talk)20:28, 12 November 2020

It should be noted that [skr] was just approved by the languages committee of the WMF, for creation of Wikipedia at least. For now all Wikimedia projects are still in Incubator.

Here on this wiki, it will remain [skr-Arab] (which is already enabled), even if there are 3 other scripts (including an historic Indic abugida, Multani, which was specifically used for that language; plus Devanagari and Gurmukhi, or Latin transliteration sometimes used today.) This won't block the import and creation of the new Wikimedia wikis (using mainly the Arabic script) as they work already in Incubator: the code [skr] can then remain disabled on Translatewiki.net (and because it was already disabled, there's no need to merge an inexixtant [skr] dataset with the existing [skr-Arab] dataset).

Verdy p (talk)21:02, 22 November 2020
 
 
 

Courtesy vanish me

Please courtesy vanish me, i accidentally created this account and then started doing some random stuff.

-Ipkap21:59, 13 November 2020

Just don't use your account here. Deleting an account is not possible.

Raymond09:51, 21 November 2020
 

Translatewiki.net does not have a mobile view (MobileFrontend and MinervaNeue)

Hello, I saw that translatewiki.net does not have a mobile view composed of the extension MobileFrontend and the MinervaNeue Skin. Please you can to add a mobile view to translatewiki.net? Thanks.

Rodney Araujo (talk)14:02, 20 November 2020

[kcg] New Language Addition (Tyap / Katab, A̠lyem Tyap)

See the request made by Kambai Akau on Category talk:User languages.

Verdy p (talk)09:05, 20 November 2020

Language name correction (Southern Luri/luz)

Hi. The Southern Luri language(luz) name is misspelled and needs to be corrected. How can I change it from "لئری دوٙمینی" to "لری دۊمنی"?

Sahh (talk)19:15, 17 November 2020

It's the name built into MediaWiki for the "#language:" parserfunction, and its source is the name imported from Unicode CLDR, where it was vetted. It seems that the name is correct is I look at Wikipedia which cites it as well. The difference being in the optionaml notation of vowels, which may be simplified (your proposal) or more advanced. I do not see a typo, and the CLDR vetted data is considered reliable (a defacto worldwide standard for translation of language names, beside the ISO 639 standard and the IANA database for BCP47 that just give English names). If I look at Glottlog and the Linguist list, we see several orthographic variants for the native language name (they vary depending on authors, sources, or time, or location of the author using an orthographic system from several possible countries).

Verdy p (talk)16:35, 18 November 2020
 

Hi, I have noticed two small errors in the original while I was translating SWViewer:

https://translatewiki.net/wiki/Wikimedia:Swviewer-about-frame-data-ref-2/en

Should say "This data is available to the public."

https://translatewiki.net/w/i.php?title=Wikimedia:Swviewer-about-frame-data-desc/en

"Appication" instead of "Application"

Best,

Jan Myšák (talk)22:27, 10 November 2020

Shouldn't data be plural only (and collective, uncountable) in English so that it should be:

These data are available to the public.

To speak about a single data element or to count them, you need another noun: "piece(s) of data", "data element(s)", "data item(s)"

Verdy p (talk)20:08, 12 November 2020

These have been fixed.

Nike (talk)15:33, 18 November 2020
 
 

Minor web site enhancements

  1. The page Translating:New_project in its last paragraph has the expression "e-mail" (as a possible way to contact staff at translatewiki.net). A reader whom I sent to look around suggests to make it a link.
  2. If you follow the link "Translating talks for projects" at the beginning of the "Support" page, you get a list having more than a handful of irrelevant and outdated pages included. Can that be changed? --Purodha Blissenbach
09:16, 8 July 2011

Bump.

Nike12:31, 28 July 2011
Edited by another user.
Last edit: 12:22, 13 November 2020

So fix it, Niklas, instead of bumping this?

Siebrand10:49, 2 August 2011

I've forgotten what is our default email address.

Nike13:44, 3 August 2011

translatewiki at translatewiki.net.

Siebrand14:33, 3 August 2011
 
 
 
 

MediaWiki:Notification-bs-pageassignments-user-group-add-summary

The last revision to this message I see is “You have been added to group $4 that have pages assigned to them”.

This message needs a documentation update, a GENDER magic word for “You have been” (so the name of the current user account must be passed as a parameter) and possibly a PLURAL magic word for $4 if it still can be a comma-separated list of groups.

EDIT: I noticed similar errors in other messages: MediaWiki:Notification-bs-pageassignments-user-group-remove-body, Notification-bs-pageassignments-user-group-remove-subject, MediaWiki:Notification-bs-pageassignments-user-group-add-body, MediaWiki:Notification-bs-pageassignments-user-group-add-subject. All of these are marked as outdated in the translation tool.

The group manager's username (the person who is adding or removing the addressee from a group) is omitted and probably isn't necessary in any language, but the addressee (the currently logged user who's reading the notification) is mandatory.

Thank you, and I hope my explanation isn't confusing.

ArenaL5 (talk)20:33, 10 November 2020

Maintainer per email informed. Hopefully he will answer here.

Raymond08:50, 12 November 2020
 

Thanks for this feedback! I have created an internal ticket to address this. Will be fixed soon. Reference is ERM21752.

Osnard (talk)15:41, 12 November 2020
 

Translations by ChoiChong

A thread, Thread:Support/Translations by ChoiChong, was moved from here to User talk:ChoiChong. This move was made by Nemo bis (talk | contribs) on 9 November 2020 at 09:15.

Delete MediaWiki:Dberr-info/hif-latn

Please delete MediaWiki:Dberr-info/hif-latn, its just a copy of the English version of the message. Thanks, --DannyS712 (talk) 02:24, 24 October 2020 (UTC)

DannyS712 (talk)02:24, 24 October 2020

Not this alone :-( I looked through the file and see some hundred "translations" into English. Any chance for an automated comparison and deletion process?

Raymond15:21, 25 October 2020

So I really quickly hacked a script together:

var notTranslations = {};
Object.keys( maybeTranslations ).forEach(
    function ( key ) {
        if ( maybeTranslations[ key ] === englishVersions[ key ] ) {
            notTranslations[ key ] = maybeTranslations[ key ];
        }
    }
);

and then retrieved the list of messages in notTranslations. I got a list of 520 different messages that exactly matched the English version - I couldn't find a way to collapse the list if I were to paste it here, so I dumped it on my sandbox on metawiki - format is message name and then the text - see https://meta.wikimedia.org/w/index.php?title=User:DannyS712/sandbox&oldid=20632414

DannyS712 (talk)08:07, 9 November 2020
 
 

RC Wikidata

I'm searching for the MediaWiki-page that shows "Show/Hide Wikidata" in the Recent Changes. Anyone know which one that is? --Ooswesthoesbes (talk) 09:52, 20 July 2017 (UTC)

Ooswesthoesbes (talk)09:52, 20 July 2017
Edited by 0 users.
Last edit: 01:02, 27 July 2017
Liuxinyu970226 (talk)01:02, 27 July 2017
Edited by 0 users.
Last edit: 10:42, 31 July 2017

That might be it. Thank you!

Ooswesthoesbes (talk)10:42, 31 July 2017
 
 

Error on MediaWiki:Wmobile-copyright/en

Hi, can someone change MediaWiki:Wmobile-copyright/en to use quotation marks rather than apostrophes in the links as they're currently broken

Thanks

Nintendofan885T&Cs apply14:25, 26 October 2020

Single quotation marks are valid in the HTML syntax for attributes.

Remember that this resource is NOT written using the Mediawiki syntax, but the plain HTML syntax, so even if it does not render correctly on this wiki, this is only because this wiki attempts to parse it as Mediawiki (where even the <a href="URL">text</a> is not permitted by the wiki; so if it was written using the MediaWiki syntax and rendered by MediaWiki, it would be .[URL text] instead; this is not the case here).

So changing the ASCII single quote to ASCII double quotes would not change the way this message is rendered here on this wiki. Keep it in plain HTML: the message is intended to be rendered only locally by the Mobile app (which uses its own internal HTML renderer with its own embedded browser component, and does not parse the Mediawiki syntax, this text is emitted as is) and NOT on a MediaWiki server...

Nothing is broken here!

Note: you are still free to change these quotes in translations, as long as you use a valid HTML syntax (so don't change the ASCII < and > delimiting the HTML opening and closing tags. As well only use a plain URL (which you may need to change if it has to link to another translated page on the same target site, and keep the "https://" protocol unchanged).

And you are free to use the the quotation marks and apostrophes and all other punctuation appropriate in the target language for the text part of the link. You can test your translation by copy-pasting it in a plan-text file saved in ".html" format, and open it in your browser (unfortunately, the source message is not "meta-tagged" as using the HTML syntax; that's something that Translate wiki should propose to indicate its expected syntax, but that would also involve importing the source message with metadata in the package).

Such message, given it contains plan HTML, should also be modifible only by admins (to avoid injection of dangerous HTML code, such as link to spammed sites, or injection of bad javascript attempting to steal data or break the privacy in the Mobile app). This is something that authors of the Wmobile app should change: they can preprocess this message to generate the HTML code they will inject in their app (without the need to integrate a MediaWiki parser phase in the app itself), and only use Mediawki syntax on this wiki. But anyway this wiki is itself protected and renders the plain HTML link code, so this wiki remaing protected.

Verdy p (talk)18:01, 26 October 2020

Oh, I thought it was broken because the links broke when I clicked on them (it went to http://en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License')

Nintendofan885T&Cs apply20:38, 26 October 2020

This is a parsing bug of MediaWiki on this wiki; this won't occur with a regular HTML parser. As I said, plain HTML links are not supported by Mediawiki as Mediawiki incorrectly includes the "trailing" quote in it. That's something that MediaWiki should fix as these quotes in HTML are never taken into account, unless they are URL-encoded in HTML.

Note that in HTML both the single quote and the double quotes are valid delimiters for attributes, and which ones are valid as part of the quoted value depends on which delimiting paired quotes are used:

  • If attribute values are between double quotes "...", litteral single quotes ' in the embedded value don't need to be encoded, but double quotes in attribute values have to be HTML-escaped as &quot; (or only if the value is an URL, they can be URL-encoded as %22, which won't need any HTML-escapes)
  • If attribute values are between single quotes '...', litteral double quotes " in the embedded value don't need to be encoded, but single quotes in attribute values have to be HTML-escaped as &#39; (or only if the value is an URL, they can be URL-encoded as %27, which won't need any HTML-escapes)

Note that any single quote or double quotes by IS valid in any standalone URL (except for the leading protocol part or the host/domain part, it is valid anywhere in the optional parts: the path, the query string, fragment identifier) or any URI. Inside a standalone URI, there's no support at all for the HTML-encoding, or for the URL-encoding (which depends on the protocol and the target host/domain part in its own URL parser, but noit at all of the HTML-parser!!!).

Here MediaWiki (on this wiki) does not parse the HTML completely correctly and so it does not use the correct HTML-parsing for delimiting attributes, and then it considers the value as if it was between double quotes (no check is made about which effective delimtier is used in the HTML attribute, so it incorrectly accepts the single quote as part of it, then it takes the wrong decision).

This is effectively a bug of MediaWiki (which could be reported given that the MediaWiki should still parse HTML correctly and should be an extension of it), in its own custom parser. But as I said, this message is *not* to be parsed by MediaWiki and will be parsed by a regular HTML parser which makes the correct decision. The bug is bisible on this wiki when viewing the translated page, but it does not affect the application.

Verdy p (talk)23:17, 26 October 2020
 
 
 

attribution options?

Jen here from https://eol.org/ . I would like to display some form of attribution to the translators who have contributed to our project, in our About pages. I thought perhaps a word cloud similar to what is available at https://translatewiki.net/wiki/Special:SupportedLanguages/id. Is this consistent with translatewiki policy? If so, is there a recommended data service we should use?

Thanks!

Jhammock (talk)19:24, 26 October 2020

Error on Wikimedia:Citationhunt-instructions details/zh-hans

Hi, I'd like to request a review of Wikimedia:Citationhunt-instructions details/zh-hans please.

The original text is "Click %s to go to Wikipedia and {link_start}fix the snippet{link_end}, or %s to see another one. Good luck!", with two "%s" placeholders. The current translation only contains one "%s", which is not expected in the code. I can't read the translation but I wonder if the "or %s to see another one" part of the original message is missing?

Please let me know if there's another preferred way to report translation issues, I wasn't too sure. Thanks!

Surlycyborg (talk)18:35, 26 October 2020

Obsuser and his translations

Can someone block User:Obsuser? He's edit warring, behaves stubbornly, does not respect the agreements made between Serbian translators regarding translations, and translates too literally. For example, the changes he has made in this edit only make it difficult to understand the text. He translated "Intended blockee" as "Намењено да се блокира" (Intended to block) -- which is very unclear in general, let alone in the Serbian standard language. The previous translation was "Блокирани корисник" (Blocked user) -- which was a very natural option. Due to the same pattern of behavior, he was blocked on Serbian Wikipedia permanently more than a year ago. User:Kizule can confirm this since his mother tongue is also Serbian. Thanks in advance!

BadDog (talk)19:10, 20 October 2020

I can confirm all things which BadDog said. He (Obsuser) still doesn't understand what teamwork means.

Kizule (talk)20:05, 20 October 2020

Bump. He is like an "energy vampire" who works only on his own and consumes the energy of us who are trying to contribute.

He persistently wants to translate literally, on incomprehensible way.

And, my god, without consulting with someone else.

Kizule (talk)16:15, 25 October 2020
 
 

Transadmin

How can I be a transadmin?

--ToprakM 13:46, 24 October 2020

[Sxr] [Xnb] Translation of MediaWiki interface is not supported by translatewiki.net

Edited by another user.
Last edit: 07:37, 24 October 2020

Hla’alua Wikipedia (incubator:Wp/sxr) and Kanakanavu Wikipedia (incubator:Wp/xnb ) ,both are open test wiki of the Wikimedia Incubator. There also have valid ISO 639 language code. Due to approval of Wikipedia, translation of MediaWiki interface into their own language in the translatewiki.net is one of the requirements before a wiki can be created. But now translatewiki.net said that there are not yet enabled. We would like to know what steps are necessary to get the language enabled.

Mecytan (talk)02:46, 22 October 2020

These two related Tsouic languages (originating from a small central area in Taiwan) have their portals (Portal:Sxr, and Portal:Xnb), created since long in 2017, which you can subscribe as a translator. They also indicate already their Incubator wikis.

They are still disabled as there's no support for now in the Translator tools and statistics. Languages are enabled for translation when there's a demand and a convincing desire to start translating them (probably starting by the Mediawiki interface). However, even if this is still not enabled, you can work on these incubators and develop there some pags of terminology that you may want to discuss, and that may be needed to start translting the Mediawiki UI on this site.

This suppoort page is to demonstrate you commiment to this project and ask these to be enabled (but note that if there's no progress or there are signs that you don't work actively with Wikimedia to support the import on the Incubator wiki or on a test wiki, this could be disabled by the Translatewiki.net admins until there are more contributors taking the project seriously, notably because generating the exports from Translate.wiki.net has a cost that should find a usage on an actual wiki (Wikimedia Incubator is supported but you also need an agreement with other users of its local community to monitor the initial progress and ask for a reasonable review)

Another thing you msut discuss is some additional support in Incubator itself and in the Wikiemdia multinigual tools. Now if the Incubator goes well to the creation of a new Wikipedia, of course these languages should be enabled because the support for these languages will be demonstrated. Note that Wikimedia wikis are not the only projects that you could be working on. For example you may want to translate OpenStreetMap tools, or communication tools that are hosted on this wiki, or would like to develop a wiki for any topic outside Wikimedia, that would benefit as well of the translation of the MediaWiki UI.

You made the appropriate step here. Hope your arguments will be enough to convince an adminsitrator of Translatewiki.net for you (I cannot do that myself).

Verdy p (talk)03:08, 22 October 2020
 

Hi,

I can do this, but I want to make sure first: Who is going to do the actual translations? The two languages have very few speakers. By itself, it's not a problem, but the pages in the Incubators are quite repetitive, and the activity in the Incubators is quite low. Are there people who speak these languages, know them well, and plan to work on localization?

Amir E. Aharoni (talk)15:00, 22 October 2020
 

Start Hanja Script language for Korean

Hello. recently, Some Korean users started a new Hanja wiki and they are wanting to make Hanja Interface for their wiki. Also, in Wikimedia projects, New request for the Hanja Wikipedia is have not rejected and if LC accepts the request, It would be need of its own interfaces. according to the ISO 15924, the code kore is assigned to the Korean with hanja, so we can use the code of kore or ko-kore for it. I also have an interest in it, and more Koreans would contribute to it.

Ellif (talk)09:23, 13 October 2020

The ISO 15924 code [Kore] does NOT mean it uses only (or preferably) Hanja. This code indicates this is written in a mix of ALL scripts used in Korean, so it accepts Hangul, and Han/Hanja.

Korean by defaut uses [Kore], i.e. [ko] is a perfect synonym of [ko-Kore], just like [ja] is a perfect synonym of [ja-Jpan], ie. It uses all Japanese Kana syllabaries [Hira]+[Kana] and Kanji [Hani] (you can use [Hrkt] to indicate that all Kanjji are transcripted to kanas (Hiragana and Katakana).

Using [ko-Kore] is then NON-SENSE. Look at BCP47 and notably the IANA database which states that [ko] uses [Kore] as its default implied script. [ko-Kore] should then not be used in BCP47. It exists only for legacy applications that want to include a script subtag for all languages and do not want to perform a lookup of the language code to map it to its default script.

If you wanted to make a preference for Hanja, you should use [Hani], i.e. [ko-Hani], so that all words that have an Hanja transcription should be written with it and not in Hangul [Hang]. And as well you could do the same thing in Japanese with [ja-Hani] to restrict the use of kanas.

Verdy p (talk)10:52, 13 October 2020
Edited by author.
Last edit: 14:17, 13 October 2020

For once, I agree with Verdy p, the correct code for the Hanja script (and only the Hanja script) is ko-Hani.

EDIT: However, I see on Hanja wikis and websites that text is written in a mix of Hangul and Hanja scripts (also the case with the word given as an example on meta), maybe we should move translations in Hangul only to ko-Hang and translations for Hanja to ko?

Thibaut (talk)13:14, 13 October 2020

And it's strange that this wiki, actually uses all Korean scripts (including Hangul) everywhere in the content (I'm not speaking about the interface of the wiki itself)... So this wiki actually uses [ko-Kore] even if they want to remove Hangul (as much as possible) in favor of Hanja (I'm not really sure this is possible in modern use, unless you accept to borrow Chinese sinograms, most probably in their simplified in modern terminologies, but possibly traditional for coherence with Hanja; not sure that users will be able to read these borrowed Han sinograms, when they also are composed with phonologic traits which are appropriate to Mandarin, but most probably not for Korean).

Do you want to be inventive and create adhoc Hanjas, composed by a traditional Hanja radical and an Hangul part to replace the phonetic parts of Han sinograms? You won't be able to compose them in Unicode, so you'll fallback to use Hangul only (or maybe Latin or Cyrillic): Hangul is more complete than the basic alphabet and has many adhoc Jamos (plus a few diacritics) to compose more complex and more precise clusters that better respect the phonetic than modern Hangul which has simplified the phonology by reducing the number of jamos (the other ones being kept for historic use and encoded in Unicode even if they are not precomposable in a full syllable using a single Unicode character).

Note that Unicode contains a few clusters that don't respect the pure (L*V*T*) Hangul composition of jamos, just like Japanese has some precomposed clusters of kanas (possibly mixed with Latin, e.g. for international measurement units), and some adhoc Hanjas specific to Korean (not used in Chinese languages, Japanese, or historic Vietnamian).

Verdy p (talk)14:13, 13 October 2020
 

I don't think we should move Korean translation made in Hangul-only to [ko-Hang]. This is their normal modern form for Korean [ko-Kore].

The use of [ko-Hang] would be ONLY to propose a transliteration to Hangul of Hanjas still normally used in modern Korean.

The interest for [ko-Hang]would be to allow a site to display Hangul easily without needing a large Han font, and it may be useful for small devices that have limited fonts

Note also that [ko-Jamo] is not needed given that encoded Hangul clusters are canonically decomposable to Jamos (so rendering on low-resolution terminals that can only display aligned (non-composed) jamos is possible algorithmically. As well this easily allows generating a romanisation fully algoithmically. Only Hanjas cause problems as they require a lookup in a possibly large dictionnary (which is not fully defined and extended regularly in successibve Unicode versions; in some cases, Hanjas do not have a well defined phonology and may turn to several distinct Hangul clusters, depending on the reader, and that's probably why some Hanjas have been kept to avoid confusions, notably for proper names).

Verdy p (talk)14:29, 13 October 2020
 

Sorry, that's not how things work for Korean speakers. Nobody uses Hanja in their daily life in 2020. Proposal to mix Korean and Hanja in domain name got quite a lot of resist in 2018 when it was submitted to ICANN.

Hanja usage is basically now in the form of disambiguation and a hanja mania's area, and most words are expressed in Hangul. No hanja required for any expressions in Korean. We indeed borrow words in Hanja, but we display them in Korean. Nope. If they want to use Hanja in interface, they should be segregated in their own area, not in the way where you steal the Hangul's area.

revi11:20, 15 October 2020

Ok then, ko-Hani it is.

Thibaut (talk)14:50, 15 October 2020
 
 

You have to notice that All Korean translations in translatewiki are in Ko-hang status, not ko-kore status. After the FRAMEWORK ACT ON KOREAN LANGUAGE enacted in 2005, the language of official documents in all governments are obliged to write in Hangul only(Article 14). Also, all newspapers became Hanja only. Before 2000. So, You have thought that many Koreans like to Hanja during their Korean writings, but it goes to extinct.

If this decision goes into Korean Wikimedia community, The community will not approve your idea. Ho-hang should be the original status of Korean(ko), and gughamnun should behave the ko-kore status.

Ellif (talk)10:54, 15 October 2020

"So, You have thought that many Koreans like to Hanja during their Korean writings, but it goes to extinct."

No I didn’t think that, I know Hanja is rarely used nowadays, it was just a question, since ko and ko-Kore mean according to the IETF, a mix of Hangul + Hanja, that’s all.

Thibaut (talk)15:00, 15 October 2020

Also the Korean act applies only to official acts of the Korean governement bodies or agencies. This does not apply to all independant projects, notably wikis that are not required to use only it, and the web in general (so "ko"="ko-Kore" in IETF remains effectively, only the Korean government sticks now on using only "ko-Hang" but only for its official documents, not the informative documents and all its communication to the national or international public, and it still actively supports Hanjas in its cultural works and still works actively within the standardization bodies for Unicode/ISO 10646, notably in the IRG for the "ideographic" scripts (which should have been better named "sinographic" gen that sinograms are not purely ideographic, and there are other unrelated ideographic scripts that the IRG does NOT work on, such as "SignWriting" or various hieroglypic scripts developed far outside Eastern Asia).

Korean people in Korean-written wikis have a strong use of Hanjas (the Korean Wikipedia has many of them which are not even transliterated to the modern Hangul with an additional precision). Nothing prohibits in fact the default Korean UI [ko] to use Hanjas, even if it's rare there (but it's not forbidden at all, just a matter of community preferences, not decided by the South Korean government alone).

If there's a conflict between the South Korean governement goals and the comminuty goals, I would then prefer the addition of the [ko-Hang] locale in this wiki, so that overrides are possible for the few [ko] resources that may exhibit Hanjas (with fallback to [ko] = [ko-Kore]).

And I'm also not opposed to the addition of [ko-Hani] for the few users that still want to sponsor Hanjas as their prefered script (also with fallback to [ko] = [ko-Kore]).

In other words, we don't need [ko-Kore] here, and [ko] can remain as it is. Note that language tagging is not a requirement to use only the indicated script, it just sets a preference order (so even in [ko]=[ko-Kore] it is possible to embed Latin, not just Hangul or Hanjas, and this use is in fact not rare at all, notably for famous trademarks, including "Samsung", or international brands and compny names like "Google", "Apple", "Microsoft", Facebook", "Amazon", "IBM", "Honda", "Mercedes-Benz", and so on, or international bodies to which the Korean government bodies participate like "ITU", "ISO", or "Unicode").

In summary:

  • Adding [ko-Kore] : no, use [ko] instead (no need for this duplicate according to BCP47 rules and the IANA database), which is Sufficient for Wikipedia and Wiktionnary editions in Korean.
  • Forbidding use on Hanjas in [ko]: no
  • Adding [ko-Hang] : may be yes if there's a need for the official bodies of the South Korean governement. We have to wait for such demand for a wiki maintained by this governement.
  • Adding [ko-Hani] : many be yes for cultural reasons and if there's an intererested community to support it and prefer Hanjas in their wikis rather than the modern Hangul.
  • Adding [ko-Brai] : may be needed for blind Korean users using the Braille script, if the automatic conversion from Hangul (or worse with Hanja) is not easy to implement (and cannot work like in Chinese with their extensive dictionnaries containing normative romanizations sponsored the PRC governement, but based on Stantard Mandarin spoken language and not at all for the Standard Korean spoken language).
  • We have already accepted [ko-KP] for a different standard decided and used by the North Korean official communication, but in fact it's not actively supported because of lack of contributors and severe restrictions for local native users on the Internet. North Korean people that now reside in South Korea jsut have adopted the community rules used in South Korea and elsewhere worldwide.
Verdy p (talk)18:41, 16 October 2020

Well - I don't much care about anything about Hanja as long as no Hanja appears on [ko]. Korean-speaking wiki community's expectation is that Korean is for generally-Hangul-written and there is no need for Hanja injection - as established in w:ko:위키백과:사랑방 (일반)/2015년 제14주#한국어 위키에서의 한자 사용에 관한 의견 요청 (and w:ko:위키백과:사랑방/2012년 제40주#한자->한글 자동변환기능의 도입에 관하여 which also features wider community rejection of hanja use).

revi01:14, 19 October 2020
 

I could not accept your opinions.

  • [Ko-hang] is the same as [Ko] therefore Ko should not be moved from current status. If you are not agreed, I ask to see the Rodong Sinmun. I want to ask one more for you: Are there any people for teaching Ko-kore for Learning of Korean? As you can easily find out in Duolingo, No. Even North Korean and Koreans in China, Russia, and Kazakhstan do not use Ko-kore as for the writing nowadays. Therefore,
  • Yes [Ko-kore] for Korean with Hanja.
  • Nay [Ko-hani] for Korean with Hanja, because Modern Korean could not be expressed with Han characters only (except if you want to save out the Gugeyol, which is not accepted in Language Committee). If you are thinking about the writing Chinese in Korean way, You rather have to contribute to the Classical Chinese Wikipedia.
Ellif (talk)08:59, 23 October 2020
 
 
 
 
 
First page
First page
Previous page
Previous page
Last page
Last page