Internationalization and Localization of Phabricator.
Nov 13 2017
Nov 12 2017
Thank you. Will update the WMF task with this information.
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.