Page MenuHomePhabricator

Make translations more modular so third-party libraries can translate their strings
ClosedPublic

Authored by epriestley on Feb 11 2015, 8:00 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 24, 11:25 PM
Unknown Object (File)
Sat, Apr 20, 2:22 AM
Unknown Object (File)
Sat, Apr 20, 2:22 AM
Unknown Object (File)
Sat, Apr 20, 2:16 AM
Unknown Object (File)
Sat, Apr 20, 1:47 AM
Unknown Object (File)
Thu, Apr 11, 7:54 AM
Unknown Object (File)
Tue, Apr 9, 11:19 AM
Unknown Object (File)
Wed, Apr 3, 4:50 PM
Subscribers

Details

Summary

Ref T7152. Ref T1139. This is a little far afield, but I need to translate some "%s thing(s)" strings into English in Instances to complete the invite workflow.

This isn't currently possible because translations are not modular enough: a library can not translate only its own strings.

To fix this:

  • Define PhutilLocale, which provides a target translation language, like "English (US)".
  • Provide PhutilTranslation, which provides some strings in a target language. Libraries can subclass PhutilTranslation to supplement strings.
  • Rework PhutilTranslator to be aware of locales.
  • I also formalized test translations, silly translations, and de-hacked up the "ALL CAPS" translation. The sex/plural rules are still hard-coded for now.
Test Plan

See next two diffs.

Diff Detail

Repository
rPHU libphutil
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Make translations more modular so third-party libraries can translate their strings.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: btrahan.
btrahan edited edge metadata.
This revision is now accepted and ready to land.Feb 11 2015, 8:28 PM
This revision was automatically updated to reflect the committed changes.