Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translating SVG images, where to put? #126

Open
birbilis opened this issue Jul 13, 2017 · 6 comments
Open

Translating SVG images, where to put? #126

birbilis opened this issue Jul 13, 2017 · 6 comments

Comments

@birbilis
Copy link
Contributor

birbilis commented Jul 13, 2017

We need to translate
https://github.com/concord-consortium/lab/blob/master/src/models/chemical-reaction/reactionsExplanationFlat.svg
to Greek, but the question is where should we put the translated one it in the engine repo?

this is use by the "What is a Chemical Reaction?" interactive (https://lab.concord.org/interactives.html#interactives/sam/chemical-reactions/1-what-is-a-chemical-reaction.json) and refers to it by name (both by .png and .svg filename without path). In the lab-interactives-site I can only find .png for it, not the .svg (which is in the lab repo)

"viewOptions": {
    "controlButtons": "play_reset",
    "imageMapping": {
      "reactionsExplanationFlat.png": "reactionsExplanationFlat.svg"
    }
  },

not sure if I also need to provide a .png and in which of the two repos (and where) to put it

maybe I need to provide a "reactionsExplanationFlag_el.svg" in same folder as the existing one? and then in the Greek interactive's .json use that filename instead. Question is though, does it autogenerate the .png or something via the "imageMapping" above? else what does "imageMapping" mean there?

@ddamelin
Copy link
Contributor

ddamelin commented Jul 16, 2017

Hi @birbilis
All good questions. In porting our previous models from the Classic (Java) version of Molecular Workbench, we had references to png files. Classic MW did not support svg. However, in the NextGen MW models we wanted to support scaling to full-screen, so we've made svg versions of most images, and provided a way to map one image in place of another using "imageMapping."

In the lab-interactives repo we had both the png and the svg there, but the imageMapping instructs the interactive to use the svg file where the model refers to the png by name.

Apparently we didn't even include the png in the lab repo and just the svg with the imageMapping reference. I think it is OK to not have the png as long as the imageMapping reference is in place. (Note, one could also modify the model JSON itself to refer to the svg file and get rid of the imageMapping part of the interactive JSON, but then you would need to have a separate model JSON as well.)

As for where to put it... We don't have separate localized directories of model files and images like we do for the interactive JSON. I think it would make sense to put the translated SVG into the same location as the English version and update the translated interactive JSON to point to that file.

@birbilis
Copy link
Contributor Author

birbilis commented Jul 17, 2017

given that the lab repo (engine) changes don't update in the lab site as often as the models one uploads in the lab-interactives-site repo, it is a bit problematic

it means we have to collect all translated images (ideally from several interactives to make the addition more impactful and hope it gets faster into the site) and postpone uploading translated versions of interactives till the engine gets updated in the site (else they will appear with missing images or worse show some error at runtime [not sure how it behaves if it can't find an image or svg referenced by the model and/or the interactive via image mapping node)

some of the images I've seen do seem to be reusable and could be useful indeed to be in the lab engine itself (and they're probably already reused in other models) instead of in the lab site. If they were in the 2nd one though, maybe could update them quicker

@pjanik
Copy link
Member

pjanik commented Jul 17, 2017

We need to translate
https://github.com/concord-consortium/lab/blob/master/src/models/chemical-reaction/reactionsExplanationFlat.svg
to Greek, but the question is where should we put the translated one it in the engine repo?
this is use by the "What is a Chemical Reaction?" interactive (https://lab.concord.org/interactives.html#interactives/sam/chemical-reactions/1-what-is-a-chemical-reaction.json) and refers to it by name (both by .png and .svg filename without path). In the lab-interactives-site I can only find .png for it, not the .svg (which is in the lab repo)

Note that this is not true. Here's the file that you're looking for:
https://github.com/concord-consortium/lab-interactives-site/blob/master/src/models-converted/lab-version/1/md2d/sam-activities/chemical-reactions/original-interactives-in-pages/page1/reactionsExplanationFlat.svg

The file you're referencing is just file with the same name in a different repository (Lab framework) and it's used by one of the example interactives bundled with the engine. It is not used by the interactive you linked. Interactives from https://lab.concord.org website are stored in https://github.com/concord-consortium/lab-interactives-site repository and there are all the necessary resources.

I think it solves you're issues. The easiest approach to translate this file, would be to create Greek translation of SVG and then update image mapping like this:

"viewOptions": {
    "controlButtons": "play_reset",
    "imageMapping": {
      "reactionsExplanationFlat.png": "reactionsExplanationFlat-EL.svg"
    }
  },

You will need to put reactionsExplanationFlat-el.svg in the same directory as reactionsExplanationFlat.svg (see my link above).

Usually images are in the same directory as model files, so it's pretty easy to track them down. In some rare cases image can also live at absolute URL or be relative to interactive JSON file. Here's an example documenting it:
https://lab.concord.org/interactives.html#interactives/basic-examples/interactive-components.json

HTH

@birbilis
Copy link
Contributor Author

thanks for putting me again to the right track

I got confused, it is the PNG that was missing from the other site since it wasn't needed (due to the mapping to SVG) and somehow I remembered wrongly (after somedays that I had read the answer but hadn't found the time to work on it) that it was the SVG which was only in the lab site.

So I can focus only on the lab-interactives-site regarding those images and can easily contribute the interactives translations as they come to me by the educators, just have to contribute the image/interactive to the lab site too if I find the file there too (used by some example)

thanks again

@birbilis
Copy link
Contributor Author

birbilis commented Jul 17, 2017

Do note that if your server is case-sensitive the above example (using -EL but then speaking about -el file) won't work. BTW, since el is in small caps in ISO codes (GR country code is usually in caps and also the region specifier in more specific language codes like el-GR or en-US, en-UK etc.), I'd rather use -el.

Actually I usually write _el (underscore) suffix in the name so that the filename part that may contain dashes already is visually separate from the locale identifier. Also since a more specific code can also be used and it contains a dash, I find someFile_en-US.svg more clearly separating the language code than someFile-en-US.svg.

but I wish to keep it consistent with your practices. So, is -langCode used elsewhere and/or do you prefer - rather than the _ that I usually use in naming localized files? (some also use someFile.el.svg, but have found MacOS-X - or probably was the Safari browser's or Silverlight/Mac file dialogs, don't remember - to have issues with multiple parts in a file extension, so avoiding the multiple dot syntax)

@pjanik
Copy link
Member

pjanik commented Jul 17, 2017

el vs EL in my comment was a mistake, sorry for the confusion.
Re suffix, I'd leave it up to you. I don't think there's any convention in our image names and I don't think this is crucial. _el seems fine to me. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants