Explore how LF & LD could better manage image file size limits

[alex-larkin]

Is your feature request related to a problem? Please describe. A language project is trying to add large images to their lexical database for archival purposes. They appear to add okay in Language Forge, but run into issues when trying to sync with Language Depot, which seems to have a smaller file size allowance.

It's understandable to want to send low-resolution images for web and app applications for casual viewing, but for archival and revitalization purposes it's essential to be able to keep high resolution copies linked to entries.

Describe the solution you'd like The first step is to determine and document the image file size limitations for Language Forge and Language Depot. (See issue #1317 for this.) Then we need to explore this bigger question of "How should LF and LD manage image file size limits?"

Perhaps an ideal solution would allow uploading high-resolution images to LF. LF would then generate lower-resolution images to sync with Language Depot, and for casual viewing in web and app applications. Language Forge would also have an option to download or view full-resolution copies, with an extra click or two, near the image.

This, of course, would place increased demands on the server.

Describe alternatives you've considered Is hosting full-resolution archival images within the scope of Language Forge? If not, a team doing archival or revitalization work would need to have their own system of backing up and distributing (or, managing access to) full-resolution digital images. Careful file naming could aid in linking images to particular entries.

This solution has its own problems.

• What if there's an orthography change, or other spelling revision? The image-entry link would be lost. Unless they used a number system with a custom field, or something of the like.
• If the images are only meant to be accessed by team members, the project administrator would need to manually add and remove people as they come and leave the project, separately from Language Forge.
• Every single team needing to work with high-resolution images needs to reinvent the wheel.

Thoughts?

Additional context See issue #1317 for preliminary discussion before addressing this issue.

[alex-larkin]

Ah, we should also consider the usage, abilities, and limitations of other products in this ecosystem, such as FLEx and Webonary.

[rmunn]

The library that enforces the 1-megabyte limit is Chorus; I've opened https://github.com/sillsdev/chorus/issues/277 in the Chorus repository to serve as a place to have that discussion. The FLEx, Webonary, WeSay, and Bloom teams may be interested in contributing to that discussion, and the Chorus issue seems like the best place for that to happen.

[alex-larkin]

Thank you Robin, good idea. Let's close this issue and continue the discussion at the issue you created.