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.
- Supports the batch rename process.
- Hold off until the we fully fork from upstream perhaps?
- 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?
- Rebranding would invalidate translations, so we need to investigate.
- Create a new project on TranslateWiki rather than using Phabricator?
- Ponder is completed.
- 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, we need to prioritize use without arcanist. (See how GitHub does it)
- Git branch mapped to differential revision might be a good move.
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
- Matthew
- Last Edited
- Apr 19 2022, 20:01
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?