From the estimation meeting discussion it seemed like this is something that needs more of a discussion rather than an estimation.
@Mooeypoo Can you take responsibility for putting down the engineering decision on the ticket and closing it?

We have not yet made a decision, but we started a conversation about possible options.

For an underlying platform, the tool seems to be relatively small (two page display; SVG search page and then an edit page). The chosen platform should:

• Be lightweight and not too complex
• Give us good support for the API operations (download the SVG / Upload the SVG) that we need

Options for backend platforms

• Slim PHP
  • Small, already used in Wikimedia tools and in production
• Symphony 4
  • Can be small but robust, already used in our projects/stack

There is also a question of what to use as the front-end elements. A few points to consider:

Should the interface load from the server and be enhanced with JS
Not a must, but may give us flexibility with no-js support as well as speed

Options for Frontend platforms

There are several options for frontend libraries/platforms:

• Bootstrap
  • Pros:
    • Widely used online
    • Good for straight-forward design like all-input edit that we have
    • Easy to work with
    • Can be easily done with template engines (though, do we need any?)
  • Cons: Not following the Wikimedia styleguide
• OOUI (PHP with JavaScript enhancement, or straight-up Javascript)
  • Cons:
    • Limited to Wikimedia use
    • Not necessarily the easiest to start with outside Mediawiki
    • Relatively heavy payload to load the whole library just for 2-3 widgets (though that can be adjusted, but not 100% straight forward to do)
  • Pros:
    • Gives us powerful pre-built widgets that are cross-browser and cross-platform without hassle
    • Goes by Wikimedia style guide
    • Very good in promoting "progressive enhancement" (PHP first, JS enhances) if that's important at all
    • Includes powerful widgets out-of-the-box we might need to enhance or use (like search widget)

Outstanding questions

How do we decide the best platform for Backend/frontend?
Should we think no-js with progressive enhancement? Is this valid for the audience of this tool, or the speed considerations?
What libraries exist (in PHP and/or JS) for SVG manipulation? Do they dictate the platform choice?

I was thinking about this earlier today and it dawned on me that we already have all the work done for the OAuth bit in a Symfony stack. That's a nice plus in the Symfony column.

Should the interface load from the server and be enhanced with JS
Not a must, but may give us flexibility with no-js support as well as speed

I don't think there's much point in trying to make sure it works without JavaScript. The live SVG preview interface (which I would favor) will require JavaScript to manipulate the SVG (otherwise we have to do a round-trip for every edit and have the client reload the whole image).

@kaldari I was even looking at something like snapsvg.io and thinking about how the entire application could be JS, minus the OAuth and the upload bit maybe.

In T202768#4546988, @aezell wrote:

I was thinking about this earlier today and it dawned on me that we already have all the work done for the OAuth bit in a Symfony stack. That's a nice plus in the Symfony column.

And we can even move that stuff into a "WikimediaBundle" in order to reuse the same code on multiple projects. I've wondered if we could do the same with OOUI too, integrating it with webpack. Could conceivably make setting up a new Symfony tool pretty quick.

In T202768#4547007, @kaldari wrote:

I don't think there's much point in trying to make sure it works without JavaScript. The live SVG preview interface (which I would favor) will require JavaScript to manipulate the SVG (otherwise we have to do a round-trip for every edit and have the client reload the whole image).

That doesn't sound super, but one possible advantage is that the preview would then more closely match what's produced on-wiki. e.g. font support could differ on the client and so the displayed text could look fine while being translated, but then look different after being uploaded back to Commons.

As for no-JS, I don't have an opinion other than preferring not to switch to React or similar (because most of our projects are PHP with progressively-enhancing JS).

One news item we might want to pay attention to is that Chrome is planning to disable scripts for what it deems are "slow connections" (2G) which might make our "no-JS" experience more relevant. See the news item on Chrome status: https://www.chromestatus.com/feature/4775088607985664

To be fair, this "app" is basically a form that outputs stuff. Going no-js isn't too much of a price, it would just dictate what strategy we take.
We can easily go with html-rendered (either oojs-ui php or just twig/bootstrap) that is form-based without active preview, and enhance it with JS experience for the language selection (ULS?) and SVG preview. That would mean a good base experience for no-js and a potential faster load for everyone else, rather than people waiting on a relatively large JavaScript payload.

If we do choose to go JS-only (which is valid, if that's what we decide) we just need to be very clear on the fact of who will and won't be able to use the product, and make sure we put in some messaging for users who either have their scripts actively off, or who have it off because their connections are slower.

In T202768#4547220, @Samwilson wrote:

As for no-JS, I don't have an opinion other than preferring not to switch to React or similar (because most of our projects are PHP with progressively-enhancing JS).

I don't think it would be wise to pick yet another platform that we haven't used before. I think that at least in my perspective, when I talk about no-JS possibility, I am thinking either PHP (possibly with ooui-PHP) or HTML (with bootstrap?) and then enhance with JavaScript (ooui or anything else). While React is cool, and potentially would be perfectly suitable for this type of product, the overhead of having Yet Another Platform is too high, in my opinion, for the benefit we will get.

@Niharika Could you confirm whether or not "live refresh" of the image while the user adds translations is a required feature? This is one feature that might have a large bearing on the tech stack we use.

I'm personally inclined not to worry too much about the no-JS issue but I agree that we don't need to get into React or whatever is cool now. PHP with some JS on the front-end seems reasonable.

In T202768#4564512, @aezell wrote:

@Niharika Could you confirm whether or not "live refresh" of the image while the user adds translations is a required feature? This is one feature that might have a large bearing on the tech stack we use.

I'm personally inclined not to worry too much about the no-JS issue but I agree that we don't need to get into React or whatever is cool now. PHP with some JS on the front-end seems reasonable.

@aezell From my conversations with users, it seems like this feature would be useful. Sam made a good point that doing auto-preview using JS might not always show the same image as the one that would be actually uploaded to Commons.
My preference would be for us to do auto-preview and generate an image as close as possible to the one we upload. I'm flexible on the frequency of auto-previews. They can happen after every keystroke, they can happen after every label gets translated. If that is too hard to do, I would be okay with us having a 'Preview' button that the user can click to preview the image.

As for the no-JS experience, the image URL input, translating and uploading will work without JS. Auto-previews won't and that's an issue we can try to solve later but it's not on the priority list.

So, it sounds like we all think there's value in a no-JS version and that there's no high priority feature which makes JS 100% necessary all the time.

I think it's possibly to make this work without the auto-refresh and if the user allows JS, the auto-refresh will work. So, it's progressively enhanced?

With JS we can have an embedded SVG that's modified on the fly as the user changes the labels.

But is there some way we can (also? instead? I don't know) run it through the standard raster generating process, so that the preview is actually more accurate (e.g. uses the fonts that that system uses, rather than those on the user's system). I know SVGs I've uploaded in the past have often ended up with slightly different-looking labels when they're displayed on Commons, due to me using weird fonts locally.

And so in general, then: we're going to use Symfony?

I think the consensus was that Symfony 4 was a good way to go because it allowed for better ways to do something small like this.

If you do use Symfony, be sure to use Symfony Flex, too: https://symfony.com/doc/current/setup/flex.html

Specifically, if you use the composer create-project command it will give you Flex and a minimal project skeleton https://symfony.com/doc/current/setup/flex.html#using-symfony-flex-in-new-applications

They promise "the smallest footprint across all PHP frameworks". I'm very interested to see how it goes!

After the engineering discussion, it seems we have two main options, that depend on the focus of the feature set.

Assuming we want the "heavy" logic of creating/analyzing the SVGs to live in ONE place (either the JS or the PHP) we seem to have these two options:

• PHP-driven implementation:
  • Using Symfony 4 with ooui (php+js)
  • Pros:
    • Can allow for progressive enhancement (lower payload for the user)
    • Logic can be adapted from existing code from the svg extension
    • Straight forward implementation for the base forms
    • Preview will likely be more similar to what we get on wiki
    • Some of the code already exists in the svg translation extension, we can use and adjust that
  • Cons:
    • No-JS isn't really necessary
    • Making live preview harder to do (we'll have to ask the server for the result)
• JS-driven implementation (without no-js at all)
  • Use all-JS implementation with http://snapsvg.io/, ooui-js for frontend and with libraries for oauth, etc
  • Pros:
    • We can use snapsvg which is powerful
    • Live preview will be easier to do
  • Cons:
    • Heavy payload for users
    • snapsvg is powerful but may not present the same output ResourceLoader would -- would that confuse users?

I'm sorry I missed the discussion. I appreciate your capturing this info.

While I did mention SnapSVG, before we decide to go all-in on it, it likely bears some research to ensure it can do what we need. Has anyone taken an in-depth look at it?

In T202768#4583417, @aezell wrote:

I'm sorry I missed the discussion. I appreciate your capturing this info.

While I did mention SnapSVG, before we decide to go all-in on it, it likely bears some research to ensure it can do what we need. Has anyone taken an in-depth look at it?

Yeah it looks a bit like an overkill, we had concerns about having a full SVG editor (which we will need to then support :\)

But yes, also, snapsvg is only one option. If we do all the logic in JS, we might not really need a full fledged SVG-javascript library, we could "just" render the SVG in the browser and update it.

Alternatively, if the logic "lives" in the PHP, we could do the live preview by doing an ajax-call to the backend, get a new SVG structure, and reload the svg with JS.

So both options allow us to do live update -- the main question is where do we want the "hard core" logic to lie, and whether we want to try and get lower payload to a user.

I'm a little concerned about Chrome blocking Javascript on its own, in mobile, for slow connections... https://www.chromestatus.com/feature/4775088607985664

That said, even if we ddecide to have the logic in the PHP that doesn't mean we are giving no-JS experience; we could still only load the system if you have JS but have the initialization of the HTML in the backend, to save on JS payload and take advantage of using some of the existing code for SVG translation from the extension.

An important thing we should keep in mind when deciding this is whether the preview is actually what will be uploaded to Commons (T202768#4566352) and Sam's comment before it.

I'd like us to put all of the logic around parsing and rewriting SVGs into the PHP code. We can learn from the existing extensions and tools and hopefully avoid mistakes that others have already learned how to fix.

Then, we should use OOUI.js for the frontend so that we are using common elements that work well with translation and fallback scenarios.

For the live refresh, we should do a round-trip to the server either on a regular basis or when the user unfocuses the text field and the content has changed.

This is the least complicated approach. We can make it fancier should the users really like it and there are valuable features that are easier with that fanciness.

In T202768#4596271, @aezell wrote:

I'd like us to put all of the logic around parsing and rewriting SVGs into the PHP code. We can learn from the existing extensions and tools and hopefully avoid mistakes that others have already learned how to fix.

Then, we should use OOUI.js for the frontend so that we are using common elements that work well with translation and fallback scenarios.

For the live refresh, we should do a round-trip to the server either on a regular basis or when the user unfocuses the text field and the content has changed.

This is the least complicated approach. We can make it fancier should the users really like it and there are valuable features that are easier with that fanciness.

That all sounds good to me. Thanks for summarizing, Alex.