Jump to navigation Jump to search

Initial source[edit]

As noted in the edit summary, this from an exchange between Edward Z. Yang and Tim Starling from the wikitech-l mailing list, posted by User:Nickj. Nick - can you post confirmation here once you have got permission that they are happy to release this as GFDL. --HappyDog 01:08, 23 November 2006 (UTC)

ISO 8601[edit]

where is the ISO 8601 bug report?

All bugs should be reported on Bugzilla. --HappyDog 13:20, 2 April 2007 (UTC)

British English?[edit]

Is there any reason why this page is Internationalisation and not Internationalization? The text of the page itself as well as the text accompanying links like the one on Developer_hub use the z version as does Wikipedia ( vs Don't really care which one is used. Well that's not true, I would prefer Internationalization. But regardless we should at least be consistent. --Cneubauer 02:35, 29 August 2007 (UTC)

That's likeli becauze peoples automatikally type vot thei are uzed to, and mybee they don't recognise even that ther are differences ;-) --Purodha Blissenbach 00:31, 17 March 2009 (UTC)

Article content Localisation[edit]


Is there any way to use Localisation to translate custom words inside an article content?

What about page title in the article content?


Palanolho 17:58, 21 March 2011 (UTC)

You should check IMSLP. They use a system of templates for that. But I'm not sure if that's the standard solution. --Micru 09:18, 30 January 2012 (UTC)
There isn't any standard solution, several hacks have been used in the past. Now the Extension:Translate is providing a proper (albeit not complete yet) solution. This is offtopic for this page, by the way. Nemo 09:41, 30 January 2012 (UTC)
@Nemo_bis: Sorry I have to dig this outdated discussion, but isn't it now be feasible to convert this page to use Special:Translate? --Liuxinyu970226 (talk) 09:06, 20 November 2016 (UTC)

{{GRAMMAR}} in JS[edit]

Is {{GRAMMAR}} working in JavaScript?  « Saper // talk »  02:55, 1 March 2012 (UTC)

Font not working[edit]

Good day, when I open the Cree wikipedia ( from my work computer, I only see squares instead of Cree syllabics. First, I would like to know if that's normal or if that's bug. Second, would there be a way to fix that from the MediaWiki end since people on computers like that don't have access to change the settings of their browser or install new fonts (now I'm from a work computer, but same thing could happen from a computer in a library for example). I'm using Internet Explorer 7. I wasn't sure if that's the right place to ask that, if it isn't, could you please point me in the good direction. Thanks, Amqui (talk) 21:03, 14 September 2012 (UTC)

Yes, it's a problem with your system, it works fine with GNU/Linux (fedora 17 here).
Extension:WebFonts#Adding a new language support should explain you how to fix that problem for all users; to enable it locally you'll need a separate bug with local consensus. Further questions should be asked on the extension's talk I think. --Nemo 21:31, 14 September 2012 (UTC)

Coding convention on line length[edit]

What's the coding convention on how long lines should be? I notice that often, the lines in these i18n files go beyond 80-100 columns. Leucosticte (talk) 09:09, 18 October 2012 (UTC)

Huge TOC[edit]

This TOC is huge. Please consider collapsing it, making it float or something. Of course the better solution would be to split all the content here in different pages, leaving in this one what is essential for (new) translators. We are pointing to this page from How to contribute, so a nicer landing for newcomers would be great. Any takers?--Qgil (talk) 22:13, 31 December 2012 (UTC)

What's wrong with the TOC being long? What's important is that it's navigable. How to contribute links to the only section which is really relevant for translators, so they don't have to care about the TOC or the rest of the page (while they'd see the TOC if it was floating). --Nemo 22:39, 31 December 2012 (UTC)

Namespace localisation[edit]

I tried to localize my custom namespace the way it is described in Localisation#Namespaces.

In my LocalSettings.php I defined:

define( 'NS_MYEXTENSION', 2750 );

And in my MyExtension.namespaces.php I defined:

$namespaceNames = array();
/** English */
$namespaceNames['en'] = array(

/** German */
$namespaceNames['de'] = array(

I registered MyExtension.namespaces.php with $wgExtensionMessagesFiles, but the namespace was not available on the wiki.

When I added

$wgExtraNamespaces[NS_MYEXTENSION] = 'MyExt';

to my LocalSettings.php the namespace got accessbible by "MyExt:" prefix, but not by "MeineErw:".

Has anybody an idea what I'm doing wrong? --Osnard (talk) 08:57, 10 September 2013 (UTC)

What's your wiki's language code? --Nemo 09:07, 10 September 2013 (UTC)

Proposed additions to "Internationalization hints" section[edit]

Avoid using message strings generated by the browser[edit]

Not all MediaWiki languages are supported by any or all browsers. So strings generated by the browser may appear in a different language to the interface, or may use incompatible terms to the interface.

Avoid using message strings generated by CLDR[edit]

Not all MediaWiki languages are supported by CLDR.

Are the above proposed additions to the Localisation page advice correct? Lloffiwr (talk) 00:51, 2 December 2013 (UTC)

(Context: bugzilla:57643#c11, bugzilla:56813.) Currently the direction taken seems to be the very opposite, so even if adopted those principles wouldn't reflect the reality. Before proposing them, you should try and get at least one such usage changed in the code. I'd suggest to (find someone able to) submit a patch directly, because bugzilla reports on such matters tend to focus on unproductive theoretical discussions about who should spend time doing what rather than on concrete issues and solutions. --Nemo 13:37, 3 December 2013 (UTC)
Nemo:Are you able and willing to discuss these issues on some developer platform? Lloffiwr (talk) 11:31, 14 December 2013 (UTC)
Sorry, I would have no idea where to start. Echo i18n issues, for instance, are intractable for me. It's better to start from some marginal corner of the codebase nobody cares about and then address controversial drama-prone "in the news" areas like Echo only after the dust settles down, IMHO. --Nemo 10:41, 15 December 2013 (UTC)

Docs on when to use inContentLanguage()[edit]

Not sure if this is the best page for it, but we should have a guide for developers on when to use inContentLanguage(). Manual:Messages API mentions that it exists, while Manual:Language explains the distinction between the interface and content language well, but there's no specific guide for this and it's far from obvious. (Examples that come to my mind include messages used for autogenerated edit summaries, as well as messages defining page names like MediaWiki:Helppage, but there are surely more?) Matma Rex (talk) 17:15, 7 June 2014 (UTC)

Location of "alias" and "namespaces"[edit]

Is it possible to locate the MyExtension.alias.php or MyExtension.namespaces.php in the /i18n/ folder? I am asking if this will break the process with tw.n? Thanks and cheers --[[kgh]] (talk) 21:20, 22 January 2015 (UTC)

Here is the answer. Cheers --[[kgh]] (talk) 21:47, 26 January 2015 (UTC)

Toc right and no floating text?[edit]

Why is the ToC at the right side and has a clear-element after it, so no text floats at the left side? It looks a bit strange with the free space at the left side. I suggest to move the toc to the left side, like it is on every page, or let the text float at the left side :) --Florianschmidtwelzow (talk) 11:30, 27 April 2015 (UTC)

Are parentheses suitable as separators/clarifiers in all languages[edit]

We're discussing fixes for the flow timestamps (which currently just use "Relative time-ago", and flip to "Exact" time on mouseover). We definitely want to go back to using "Exact" as the default, with "Relative" as a tooltip.

However, if possible, we want to display both the "Exact" timestamp and the "Relative" timestamp for the first few days. Similar to the way Gmail does it for up to 2 weeks, by using parentheses - e.g. Nov 11 (1 day ago)

Someone mentioned concerns about using parentheses, for this task. The question is:

  • Are parentheses suitable as a universal separator (clarification indicator)? I.e. can the developers just use: $1 ($2)
Or must we use bulletpoint/dot/other as a separator, instead? E.g. $1 • $2
Or is there a third and preferred method we haven't considered?

I saw the section here at Localisation#Symbols, colons, brackets, etc. are parts of messages, which seems to indicate that it is completely OK to use parentheses. I also tried checking special:watchlist?uselang=foo in a few dozen non-latin scripts, and they all appeared to use parentheses in various places. So I think it is acceptable to just use $1 ($2) style format, but confirmation/correction would be appreciated. Thanks. Quiddity (WMF) (talk) 19:59, 12 November 2015 (UTC)

Parentheses must not be hardcoded. Either they are part of a message and are translatable as such, or they must be inserted via the "parentheses" system message (like this). --Nemo 20:04, 12 November 2015 (UTC)

Languages that use non-arabic numerals in their ToC[edit]

Just FYI, for now...

I noticed the Burmese Wikipedia uses non-arabic numerals in the ToC. This made me think of my global.css which tweaks the colors/size of these numbers and adds a dot-suffix (which I was previous-to-this hoping would be an easy improvement for all wikis...). screenshot comparison. So, I asked for help finding other languages which use non-arabic numerals. Here's what I learned:

Based on
but without the false-positives of: Ar, Arq, Arz, As, Hi;
and the unverifiable(?): Bho, Kk_arab, Ks_arab, Ks_deva, Ku_arab.

Hope that helps someone! (Move this elsewhere, if there's somewhere better). –Quiddity (talk) 19:29, 30 January 2016 (UTC)

For variants you have to choose them in the settings. There are no false positives, see Manual:$wgTranslateNumerals. Nemo 20:50, 30 January 2016 (UTC)
Nod, I've struck out my earlier incorrect lines, and tried to add the variants detail to the list in a way that is clear and accurate - is it? Context: I'm wondering if we can add some more details to Manual:$wgTranslateNumerals, to help future developers who are new to this (and also to update the incomplete list of 2 languages it currently has). I've taken a swing at it, with this edit, but please revert/correct/improve etc! –Quiddity (talk) 18:35, 2 April 2016 (UTC)
Your edit is good, thanks. At some point however, if you want to add many more examples, it would make more sense as its own Wikipedia or Wikibooks page on localised numerals. :) Nemo 09:10, 3 April 2016 (UTC)

Gender magic word[edit]

In my opinion Gender magic word should work in Help namespace too. I created a task on Phabricator. --Dvorapa (talk) 15:36, 13 June 2016 (UTC)

Third World languages[edit]

This section makes reference to "non-technical third world languages", which is unacceptable prejudice. What is a Third World language? There are Native languages in "First World" countries that are also non-technical in nature. Can someone please rewrite this sentence? Thanks, Capmo (talk) 18:33, 21 June 2020 (UTC)

@Capmo I rephrased this sentence: [1]. Matma Rex (talk) 14:31, 22 June 2020 (UTC)
Thank you, it's much better now! I was afraid to edit the page and mess up with the translation tags. Capmo (talk) 14:36, 22 June 2020 (UTC)

en-gb and en-ca translations[edit]

I'm wondering if there's documentation anywhere, which explains when editors should or shouldn't translate [documentation/mass-messages/etc] from "en" into "en-gb" or "en-ca"? I vaguely remember that we discourage it, but I'm not certain about the exact reasons.

Context: I wanted to suggest to an editor that they not spend any time making en-gb translations of a newsletter in the future, and I was hoping for some documentation to point them towards that explained these points (and more?).

IIUC, from memory, these are the issues...

  1. en-gb/en-ca are primarily used for technical testing of language variants and language fallbacks, [?]
  2. it is probably not a "best use" of anyone's limited time to translate into these variants,
  3. translating pages into these languages over-emphasizes English within the "Other languages" box (by making it appear multiple times and inherently near the start of the list),
  4. there is no good way to deliver mass-messages in en-gb/en-ca (unless the whole wiki is configured to have one of those as the default),
  5. unlike many (most?) other language variants, there are very few significant differences for these 3. [As a dual GB/CA citizen, I can say that!]
  6. it can lead to problems like phab:T162008, and also to the related small risk of outdated translations overriding more uptodate defaults.

If there isn't any existing documentation: Are the 6 reasons in my understanding accurate? Are there any additional reasons? And where could/should we document it all? Thank you! [Hopefully I'm not opening a "can of worms" here, though I do understand there are many many complexities surrounding this topic]. Pinging @Nikerabbit: for any insights. Quiddity (WMF) (talk) 04:35, 21 July 2020 (UTC)

It depends on the context. For page translation, I doubt there are any target pages using page language of en-gb or en-ca, so those translations would not be delivered anywhere with MassMessage. Of course one can still view those translation pages directly, if they exist. In general translation to en-ca or en-gb should not be needed for comprehension in technical documentation (as opposed to natural spoken language).
I am not certain how much of these changes could be done automatically (certainly many lexical differences would be quite easy).
In any case, while in this context there isn't really benefit to translate to these languages, having them there doesn't seem to be a big problem. Improved language selection (which may happen) for translatable pages would make the issue you point mostly moot. Nikerabbit (talk) 12:43, 21 July 2020 (UTC)