I am involved in the production of figures and tables for an eBook that is to be translated into a number of languages. I'd like to create a database of the images (about 20) with fields over the various text blocks in each image into which the translator can type their language version (around 15 per image). Each image is different, as is each text block.

My initial thought is to create one record for each language with 20 layouts (one for each image) with the appropriate unique fields overlaying the image (stripped of original text) as they would appear in the English version. 

My next thought was to have one record per language but 20 tabs (one for each image).

I feel like there should be a more efficient way to create this database, perhaps with one record for each language translation of each image but each of these will need to be dependant on one arrangement of unique fields for each different image which sounds like a single layout again and I'm not sure how the record could be related to an individual layout only. Perhaps even separate tables for each image or each language?

Is there an obvious choice that I am missing? I am not a developer, just a hobbyist and struggle with basic conceptualising such as this.

Any help will be greatly appreciated as I am keen to get started as there are some time pressures. 

Edited June 6, 20187 yr by muzz

I'd probably start with a table for image, with just an ImageID field and optionally a container for the image and maybe a name.

Then I'd add a translation table with an ImageID field and make a relationship based on that field. The translation table would have a language field, and a field for each block of text you might need (header, subhead1, etc.).

So for each image you'd have a single record in the image table, and then as many records in the language table as you need, one per translation per image.

This is not a totally "correct" structure but would be simple to set up and I think sufficient for a small project.

 

Thanks Fitch, I will give it a go.