Page MenuHomePhabricator

[BUG] Some CSS selectors break translation input
Open, Needs TriagePublicBUG REPORT


What is the problem?

This SVG shows only one translation input, when it should show ~20.

From experimenting, the problem seems to be caused by a <style> element containing:

#percentage_numbers text {
	text-anchor : end;

(It appears to be the CSS selector it objects to, rather than the CSS rule).

When I download the SVG it has not had id attributes added to the <text> elements, nor <tspan> elements added as children.

Another thing I have noticed for SVGs which have this bug is that the javascript variable "appConfig.translations", when looked at in the browser console, is something like:

Object { "": {…} }

where it should be something like:

Object { trsvg2: {…} }

This suggests that the <text> elements are not having their ids set by the tool. So, they are not being uniquely identified and it keeps overwriting the item whose key is "".

Steps to reproduce problem
  1. In SVG Translate, try to view an SVG which contains:
<style type="text/css">
  #percentage_numbers text {
    text-anchor : end;

Expected behavior: Appropriate number of translation inputs show, downloading the SVG should show it having extra id attributes.
Observed behavior: At most one translation is shown. Downloaded SVGs are unmodified.

Event Timeline

This behavior is by design. CSS selectors that use identifiers complicate the translation. examines each style element in the SVG file. It collects the CSS rules, extracts the selectors, and then it examines those selectors starting at line 181:

foreach ($selectors as $selector) {
    if (false !== strpos($selector, '#')) {
        // IDs in CSS will break when we clone things, should be classes
        $this->logFileProblem('File {file} has IDs in CSS');
        return false;

If SVG Translate sees a selector with #, then it gives up on the entire file. SVG Translate logs the issue.

SVG Translate is appropriately worried about ID selectors. SVG Translate wants to copy elements, and when it copies an element, then it should change the id of that element. Changing the id may confuse formatting for the copy.

SVG Translate could be more circumspect about handling such files. It could process elements that do not contain any id that was found in the style elements. That test might be involved, because the id might be a text element, or it might be in one of the included tspan elements (or textPath elements if that feature is ever added).

It would be better for the SVG to avoid ID selectors and use class selectors instead. That would make the SVG file compatible with SVG Translate. Maybe the log message could offer some help about modifying the SVG file.

Using ID selectors is uncommon, so it is not a significant limitation for SVG Translate. The rarity suggests it is not worth the effort for SVG Translate to process ID selectors. The strategy of giving up on the entire file is a reasonable choice.

I would change this issue from a bug report to a feature request of handling CSS with ID selectors.

I would put a low priority on adding the feature.