April 19, 2022
Event: {E3}
Attendees:
Agenda Items and Notes:
- Action item check-in
- @Matthew Discuss banner on T15012: Update Diviner documentation to reference Phorge
- @Matthew Create task and discussion around integrating Askimet.
- @20after4 - Lock down what we can on this install, make notes on what we can't install.
- @20after4 - Create a banner for the frontpage to show people how to contribute (Link to ponder, info on trusted contributors)
- @dcog Investigate Rector: https://getrector.org/
- Deploying changes
- Chris to make a task in regard to having Harbormaster: T15092: Automatic deploy onto we.phorge.it
- Rebrand Effort
- Rector comments and discussion
- Concerns over upstream-ability, but seems useful.
- Main concern: Automatic renaming of "Phabricator" to something else is not likely to be accepted upstream. Our current approach outlines first trying to rephrase text to remove the platform name altogether (e.g. refer to simply as "the installation").
- Supports the batch rename process.
- Hold off until the we fully fork from upstream perhaps?
- Concerns over upstream-ability, but seems useful.
- Renaming
- We need to rebase against upstream to get changes discussed with Evan. Dan to try, but anyone else is welcome to as well.
- There is a tool that can rename the classes dynamically on the fly: https://secure.phabricator.com/T13658#255996 - To be investigated
- Perhaps we use runkit to log, then watch on our upstream instance?
- The rebranding approach of changing the pht() keys will invalidate a lot of existing translations. Investigate if there are ways to avoid this.
- It might be possible/reasonable for the rebrand effort to work by adding a new translated language, e.g. "English - Phorge", where none of the pht() entries are changed but instead get "translated" to new phrasing that doesn't mention Phabricator. This feels a bit hackish but might be a reasonable (short-term?) path forward without breaking existing translations and might be easier to crowdsource.
- Create a new project on TranslateWiki rather than using Phabricator?
- Ponder is completed. Keep this more open to community than e.g. Maniphest, so that Tasks are relegated to known work to be done whereas anyone is able to ask questions.
- Liked by team, seems good.
- Rector comments and discussion
- Prototype Applications
- @Matthew to collect list of prototype and deprecated applications, make a task for each.
- It would be wise to investigate why each application is prototype, and include on each task.
- Community Migration
- Arcanist is a pain point and also tends to be a barrier to adoption. We should prioritize addressing these pain points.
- See https://secure.phabricator.com/T5000 (using Differential with plain Git and not need Arcanist)
- This would likely mean having Phabricator knowing which branches to track and any branches being pushed which are untracked would be converted into a Differential Revision instead of public branch.
- Similarly for Mercurial this would likely mean translating their "topics" into Differential Revisions.
- The long and sordid tail of @20after4 vs the arcanist haters is detailed in T15096: Discuss Arcanist as a barrier to adoption of Phorge and how to address the underlying issues. - sorry I missed the meeting but this was over-due for me to write down somewhere. ---
Action items:
- @Matthew Create task and discussion around integrating Askimet.
@speck Create task about auto deployment to upstream.- @Matthew collect list of prototype and deprecated applications, make a task for each discussing what to do.
- @speck Investigate usefulness of using translations to help with rebrand process.
- @dcog Proof of concept to work around language issues.
- Last Author
- 20after4
- Last Edited
- Apr 25 2022, 07:42
Event Timeline
FYI, it seemed that the issue with the wiki preview loading may be been related to tagging names... if the tags are removed, the preview loads
As I started to thinking about the script to process the pht() files, it hit me that converting something something like:
pht('Connect to Phabricator install specified by __uri__.')
into
pht('Connect to {} install specified by __uri__.', $platformName)
Is something that Rector could likely automate as well... taking a look at their default rules overview https://github.com/rectorphp/rector/blob/main/docs/rector_rules_overview.md
I noticed that there's a rather inviting contact page on the Rector site: https://getrector.org/contact
I'm not sure if they sell support or what, but I'm thinking I really want to try contacting. Does anyone else thinks that's a worthwhile idea? Perhaps they would want to join in some capacity...
If anyone has any ideas about anything to say, or if you think it's not a good idea to contact, or if someone else besides me should do the contacting, just let me know
There is quite a bit of text that is setup like this:
pht( 'blah blah blah %s blah blah'. 'blah blah Phabricator blah %s'. 'blah blah.', $var1, $var2);
Adding a new placeholder in that text would need to be refactored to look like this
pht( 'blah blah blah %s blah blah'. 'blah blah %s blah %s'. 'blah blah.', $var1, $phabricator_product_name, $var2);
I would guess this complicates the refactoring that's necessary since it has to be aware of the positional arguments of a concatenated string and insert the new argument in the appropriate position (and declare the variable somewhere possibly).
I don't think it could hurt to reach out and contact them to ask about this sort of thing.
translations,The rebranding approach of changing the pht() keys will invalidate a lot of existing translations. Investigate if there are ways to avoid this.
What if we make a new Phorge project on TranslateWiki and use the API to transfer in bulk?
@speck Would it be totally unreasonable to instead do:
pht( 'blah blah blah %s blah blah'. 'blah blah @@PHORGE_INSTALL_NAME@@ blah %s'. 'blah blah.', $var1, $var2);
And have pht recognize the identifier and pull it from configuration?