- User Since
- Jul 7 2015, 9:05 AM (210 w, 3 d)
Nov 23 2016
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:
- 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).
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.
Okay, I have been thinking this for a bit. I don't have a perfect solution, but I have the following proposal.
Nov 8 2016
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:
When multiple variants exist, should we export a nested structure like this?
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
- When exporting, I don't know how to escape $ for Translatewiki (this affects ~10 strings).
May 24 2016
Naturally people can work on what they want – that is the promise of open source. I am not contesting that. What I do want to make sure is that our values and goals are aligned. For example you and we recommend people to collaborate first. If we are sufficiently aligned, I don't see much need to continue discussing about things that might or might not happen.
If we submit patches, say once or twice a week, will you be able to review and merge them before the become stale?
Usually, yes, but I can't promise we'll always be able to review patches promptly.
Like you say, Phabricator is a big project. This means I am willing to give some amount of special treatment to it that I would not give to smaller projects because that would not scale. For example, requiring all messages to have message documentation up-front is unreasonable. But a good way forward would be to establish good practices such as:
- having message documentation for new or changed messages;
- accepting bug reports and patches about source texts;
- and enhancing and enforcing best practices in code review with regards to parameters, plural handling etc.
Jul 7 2015
The Lato font is causing problems for some people, including me. See https://phabricator.wikimedia.org/T104047#1419642 for example or the screenshot below.