Page MenuHomePhabricator

Phabricator and translatewiki disagree over how to indent JSON files
Closed, ResolvedPublic

Description

Discovered while working on T318763 - the scripts that produce JSON files from the Phabricator repo produce JSON files indented with two space (which is hardcoded somewhere along the line in Arcanist), whereas translatewiki produces JSON files indented with one tab. Since both scripts update qqq.json, this produces inconsistencies and dirty diffs that should be fixed.

Event Timeline

Nikerabbit moved this task from Backlog to External on the translatewiki.net board.

indented with two space (which is hardcoded somewhere along the line in Arcanist)

That seems to be return str_repeat(' ', $depth); in https://phabricator.wikimedia.org/source/arcanist/browse/wmf%252Fstable/src/parser/PhutilJSON.php$146-159 .
I'm curious if we could simply overwrite that with a tab or if in theory anything could break (which shouldn't).

Tested https://gitlab.wikimedia.org/repos/phabricator/arcanist/-/merge_requests/3 by going to http://phorge.localhost/file and uploading a random JSON file and checking the rendering.

Before, using upstream return str_repeat(' ', $depth); :

image.png (836×939 px, 123 KB)

After, using custom return str_repeat("\t", $depth); :
Screenshot from 2024-06-10 18-31-29.png (836×939 px, 124 KB)

I guess we have a trade-off here between reading JSON on smaller screens versus making translatewiki.net happier.

Deployed on 2024-06-25; setting status to resolved.

Change #1049599 had a related patch set uploaded (by Pppery; author: Pppery):

[phabricator/translations@wmf/stable] Export source strings again so en.json is indented with tabs

https://gerrit.wikimedia.org/r/1049599

Change #1049599 merged by Aklapper:

[phabricator/translations@wmf/stable] Export source strings again so en.json is indented with tabs

https://gerrit.wikimedia.org/r/1049599

I guess we have a trade-off here between reading JSON on smaller screens versus making translatewiki.net happier.

CSS tab-size can be used here if desired.

Also, this seems like something that should be less opinionated in a CMS and otherwise dictated by a language's rules. Some default is probably reasonable, but probably this should be a config option upstream.