Another option that some svg editors use is to use namespaces to embed an html div tag which supports word wrapping. There are probably significant downsides to doing this, but if we are listing options it probably bears mentioning

That would not be easily possible. There must be something like a "max-width" aka content area https://www.w3.org/TR/SVG2/text.html#TermContentArea value for the relevant text areas. I mean the same considerations were suggested with Flow-text, which comes not in the final SVG (1.1) specification.
If we would support SVG 2 it would indeed be easy, as it uses the "Auto-wrapped text" https://www.w3.org/TR/SVG2/text.html#TextLayoutAuto.

In T202771#4532896, @Perhelion wrote:

That would not be easily possible. There must be something like a "max-width" aka content area https://www.w3.org/TR/SVG2/text.html#TermContentArea value for the relevant text areas. I mean the same considerations were suggested with Flow-text, which comes not in the final SVG (1.1) specification.
If we would support SVG 2 it would indeed be easy, as it uses the "Auto-wrapped text" https://www.w3.org/TR/SVG2/text.html#TextLayoutAuto.

Yeah, this is going to be hard. This task is to figure out the simplest solution (using SVG 1.1). I understand that SVG 2.0 comes with some breaking changes that will not play nicely with many image editors.

Ignoring subscripts, font shifts, and other exotica:

100. Don't do it

1. One-for-one text as SVGTranslate.

3. Merge/Split where users breaks lines. Put the TU source and target into textboxes with newlines where a tspan starts a new line. The translator puts newlines where he wants line breaks. The tool converts the newlines back to tspans. Translation database is never told about line breaks; linebreaks only stored in SVG.

2. Tool breaks lines at trivial points. Learn inline-size. Put the source/target in a one-line text element, use the SVGDOM to find the text positions of whitespace chars (+ ­), and build the result into an SVG 1.1/2.0 compatible multi-line text element. Text.getNumberOfChars(), .getStartPositionOfChar(), .getEndPositionOfChar(). Kerning, letter-spacing, and word spacing can be free. Small issue with text-anchor and whitespace.

4. Put linear text into HTML p element, set font, set xml:lang, set dir, set left/mid/right, set CSS width, and copy HTML's result to SVG text element.

Generally, the tool should only expect 1 to 3 lines; figures should not have complicated text. There's a vertical aligment issue akin to text-anchor.

Also see: T203444: Way to change word order?

A typical translated label:

      <switch>
        <text systemLanguage="ru">
			<tspan>Нервный</tspan>
			<tspan x="-8" y="20">гребень</tspan>
		</text>
        <text systemLanguage="de">Neuralleiste</text>
        <text systemLanguage="hr">
			<tspan>neuralni</tspan>
			<tspan x="-6" y="20">greben</tspan>
		</text>
        <text>Neural crest</text>
      </switch>

With offsets for separate lines defined basically by hand, I don't see how we can implement this short of making a mini visual SVG editor.

The cited example is from File:Neural_crest.svg

https://commons.wikimedia.org/w/index.php?lang=hr&title=File%3ANeural_crest.svg

There's a bit more going on with that translation unit. Here's more context:

    <g transform="translate(106,446)" style="font-weight:bold;text-align:end;text-anchor:end">
      <switch>
        <text systemLanguage="ru">
			<tspan>Нервный</tspan>
			<tspan x="-8" y="20">гребень</tspan>
		</text>
        <text systemLanguage="de">Neuralleiste</text>
        <text systemLanguage="hr">
			<tspan>neuralni</tspan>
			<tspan x="-6" y="20">greben</tspan>
		</text>
        <text>Neural crest</text>
      </switch>
    </g>

The artist is correctly trying to right align (text-anchor:end) the translations, but the artist has been confused by xml:space rules and SVG's text block processing. The desired result without tweaking x is obtained by

    <g transform="translate(106,446)" style="font-weight:bold;text-align:end;text-anchor:end">
      <switch>
        <text systemLanguage="ru">
			<tspan>Нервный</tspan><tspan x="0" y="20"> гребень</tspan>
		</text>
        <text systemLanguage="de">Neuralleiste</text>
        <text systemLanguage="hr">
			<tspan>neuralni</tspan><tspan x="0" y="20"> greben</tspan>
		</text>
        <text>Neural crest</text>
      </switch>
    </g>

The 'x' attribute is needed to reset the x-coordinate. Starting a new XML line (putting whitespace #text) between the two tspans puts a space at the end of the first tspan, and the fudging of the x attribute shifts the second line left to account for that extra trailing space (fudging makes the two lines end at about the same x-coordinate). You can see that on the file page because Russian and Croatian have more space between the end of their first line and the start of the leader than the other languages. Instead, the XML should follow xml:space rules and not have any whitespace between the two tspans. The space between the two words has been added inside the second tspan to make text selection give the correct result ("Нервный гребень" rather than "Нервныйгребень").

Even if xml:space rules are ignored, the end result is only off by one space (indented lines are much worse under xml:space="preserve" rules).

My analysis indicates that there's no particularly good way to do wrapping in SVG 1.1. The standard itself only suggests embedding XHTML. This kinda works (you need to remove <body> from their example, otherwise MW's upload filter rejects it), however it raises questions how well it's supported and whether this will open door for new exciting security holes. The punchline is that you still need to specify the size for <foreignObject> somehow for wrapping to happen. So unless the creator has created some particularly weird XML for labels by hand, it would be hard to achieve wrapping. I think we should just document this as a known problem and move forward without it.

In T202771#4585213, @MaxSem wrote:

My analysis indicates that there's no particularly good way to do wrapping in SVG 1.1. The standard itself only suggests embedding XHTML. This kinda works (you need to remove <body> from their example, otherwise MW's upload filter rejects it), however it raises questions how well it's supported and whether this will open door for new exciting security holes. The punchline is that you still need to specify the size for <foreignObject> somehow for wrapping to happen. So unless the creator has created some particularly weird XML for labels by hand, it would be hard to achieve wrapping. I think we should just document this as a known problem and move forward without it.

So you're saying that out of the three (well, two) proposed solutions in the task description, neither is doable?

You're concentrating on UI of this while I'm explaining that trying to wrap text in SVG is problematic in principle.

In T202771#4591630, @MaxSem wrote:

You're concentrating on UI of this while I'm explaining that trying to wrap text in SVG is problematic in principle.

I know it's problematic. I'm trying to understand the extent of it. What are the ways we can make this less of a problem? I'm not looking to fix every single problem case out there. I'm looking for what we can do from a technical+UI perspective to make this easier on the users, if that makes sense.

I think we discussed that we can also use this tool to educate user. Maybe wrapping is another place where we can alert the user of the limitations of the tool and point them to something like Inkscape if they have that particular need?

It would allow us to provide a tool for the simplest of cases and, if it provides value, build on it in the future for more difficult situations.

@MaxSem - Do we know how either of the existing tools would handle the example you provide? Would they just ignore the tspans or what?

In T202771#4595400, @kaldari wrote:

@MaxSem - Do we know how either of the existing tools would handle the example you provide? Would they just ignore the tspans or what?

They understand tspans and offer you to translate them, however they neither can create new tspans (e.g. if a label in Russian is longer than an English one and needs two lines instead of one) nor can they position tspans to make text look properly aligned.

It seems like a reasonable compromise that we would do something similar.

That is, we'll let you translate existing tspans but alignment or creation of new tspans is outside the use case for the tool.

Is that acceptable, @Niharika?

I think this investigation has digressed into a different problem than the one I described in the task description.
Let me try to explain that more clearly: The problem is that sometimes a text label is broken up in the UI while it is meant to be a single phrase. This makes it harder to translate it properly. See the example I give in the task description ("Collective Municipality").
What I was hoping this investigation would do is to come up with a suggestion for the best way to mitigate this problem from the user's perspective. I proposed a couple solutions in the description. Are those plausible? Are there better ways to do this that I haven't thought of?

If a user adds a translation that creates alignment issues - that is okay for now. The user can make use of the Preview feature to see if a label is longer than it should be and doesn't wrap and they will fix it.

Thanks for the clarification.

Based on my understanding, I think the first option is easier and maybe indicates to the user more clearly that we aren't going to merge multiple lines. I think it makes it easier to keep track of what text goes into what container in the SVG code.

@Niharika It looks like we settled on a solution to this in T206712. Can we close this one?