Thank you. Will update the WMF task with this information.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 13 2017
Nov 12 2017
Nov 11 2017
The tools to perform this export are available in that project already. We don't plan to run the tools for you, since this just makes the workflow more complicated: you already have access to the tools you need to do this yourself.
Sep 22 2017
Sep 21 2017
Aug 22 2017
Another user mentions project icon names are not translatable, which is I presume the same issue. That extendable options are not translatable,
Aug 20 2017
Apr 7 2017
Feel free to submit patches for these!
Apr 3 2017
Mar 16 2017
Do this man
Mar 15 2017
Awesome (thanks for the super fast answer)!
My belief is that we've satisfied all the requirements for Translatewiki to move forward on their side.
Seeing the long list of merged commits here (thanks Evan and Nikerabbit for elaborating and explaining needs!), are there any further code changes in Phab needed before someone could set up a "Phabricator" project at http://translatewiki.net and let volunteers start contribute translations?
Mar 12 2017
Yes, it is not "incorrect" but it is not human-readable format problem same with T8973 either. Chinese / Japanese / Korean unicode should be shown as what it is instead of some unreadable unicode digitals, especially in TRANSLATION functions, otherwise how to translate and confirm that?
Mar 11 2017
This behavior is not "incorrect", it just isn't the most human-readable format we could use. I'm going to merge this into T8973, which discusses this and other potential improvements to human-readability for JSON encoded for presentation.
Mar 3 2017
Feb 16 2017
Jan 17 2017
Nov 23 2016
Sure, not a problem.
We now export a frequency.json, with string keys in a list. Since we haven't actually collected frequency data, the order is currently (roughly) random:
We now export strings into projects/<project>/<group>/en.json, etc. For example, here are strings which appear ONLY in Maniphest:
Okay, I believe we already produce a format which is compatible with that definition:
- Proto-english strings.
- Nested English translations.
- Variable types.
- Usage frequency information ("this string has frequency 0.9 out of 1.0", or "this string is part of the 'most common 10% of strings' group").
- Application groupings ("this string is part of Maniphest").
- Places in the code where the string appears ("this string appears at x.php line 234").
- Additional human-readable context information, like "qqq" (very rarely available).
Maybe it would be simplest if you just give me an example of exactly what you want us to emit?
What works out of the box is JSON files with string key-value pairs for source text. For documentation the qqq.json that is "just-another-language" is what we use most often. The strings of that file are parsed as wikitext using MediaWiki syntax and displayed automatically to translators.
That sounds fine to me. Do you have any preference on what format you'd like the proto-english + variable type annotations in? Maybe something like this, since it sounds like you're doing some level of custom stuff on your side anyway?
Okay, I have been thinking this for a bit. I don't have a perfect solution, but I have the following proposal.
Nov 20 2016
Nov 10 2016
Pausing this from our perspective since we're waiting on guidance to move forward.
Nov 8 2016
Sounds good, thanks!
In other words is your array syntax always messagekey[gender][plural] or could it also be messagekey[plural][plural] depending on the variables?
We support unlimited gender/plural variants in any order. We have a number of strings like this:
%s cannot be repeated as far as I know.
When multiple variants exist, should we export a nested structure like this?
[...]
"aBmeIEk": { "one": "%s star", "other": "%s stars" },
In T5267#199335, @epriestley wrote:Variables such as $1 are not part of the spec, and it makes no difference to us if you use %s instead. So unless this conversion is required by your system, you can drop it.
At least some translators are likely familiar with $1, {{GENDER:$1|X|Y}}, and so on, right? And you have documentation on this syntax to help translators who aren't familiar with it learn it?
Here are the current internal data formats:
Variables such as $1 are not part of the spec, and it makes no difference to us if you use %s instead. So unless this conversion is required by your system, you can drop it.
Some of the terms that I use below (e.g. outdated) are explained in https://www.mediawiki.org/wiki/Help:Extension:Translate/Glossary
Nov 7 2016
The rTRANSLATEWIKI repository is now available. Here is an example of the en.json MediaWiki-style JSON string file we currently generate:
I don't know what this means. $ in the string contents isn't anything special for translatewiki.net.
- When exporting, I don't know how to escape $ for Translatewiki (this affects ~10 strings).
Likewise, when importing, I don't know how to unescape $.
Nov 6 2016
The technical definition of "Limited" is that it has fewer than 512 strings, including 0 strings.
In T5267#199144, @epriestley wrote:
- Did you notice that "Spanish (Spain)" was under the "Limited Translations" heading, instead of the "Translations" heading?
I think D16810 should get this started, at least. Known technical issues:
@MZMcBride, couple of questions so we can improve this:
Oct 30 2016
I would subscribe to the Paste, and spend 20 seconds updating the file if it changes. Like I mentioned before, this task has already been prioritized and we're not going to work on it until other things in the prioritization queue have been completed. I think self-maintaining is a reasonable work-around.
It looks like T10814, specifically T10814#170824, provide some useful info. Thank you for that link!
I would like to submit a translation to upstream. Where do I start?
P1792 is the German example.
If you want to pursue i18n ahead of the upstream, T10814 has some walkthrough I did with another user. It's basically, dump strings into a file, translate, add to src/extensions. https://secure.phabricator.com/w/community_resources/#translations has examples of Chinese and German users have shared here.
Everything you mention is covered by this task.
In T5267#198537, @chad wrote:The current status is the infrastructure is provided, but the translations are not (you need to either translate it yourself, or check the community wiki page here for community contributed translations). Then install said translations locally.
The current status is the infrastructure is provided, but the translations are not (you need to either translate it yourself, or check the community wiki page here for community contributed translations). Then install said translations locally.
I'd like to get this task un-stuck. I'm unclear on Phabricator's current internationalization capabilities.
Aug 25 2016
Aug 18 2016
Aug 15 2016
Aug 4 2016
I've changed and added some translation in the Paste. In Addition you can change two config variables to have german Maniphest status and priorities :
Jul 23 2016
I've not looked into the details of the implementation you started, but because it's gettext I thought maybe some links wouldn't harm:
Jul 12 2016
T11319#185560 has some additional discussion about somewhat-related-ish issues.