I'm glad to hear that setting a flickrSetId has proved to be a suitable workaround for you.
Thank you for letting me know.

You're welcome.

Please feel free to post suggestions for future versions in the Feature Requests forum thread.
This keeps all the ideas together and ensures that they are not overlooked by the developers.
Thank you.

Yes. Please check out the Embedding Multiple Galleries support section.
There are online examples of embedding multiple galleries on a single web page and on separate web pages (and also an example of switching between galleries on a single web page).

With Juicebox-Pro, you can create as many individual galleries as you like. However, if you would like to link them all together (with a navigation menu), then you would need to do so manually following the examples in the Embedding Multiple Galleries support section (link above).

If you are looking for an automated solution to creating and listing multiple galleries, then we have another product that you might be interested in called Showkase.

Showkase is a PHP web application which allows you to create a complete portfolio web site (integrating multiple galleries) online.
Showkase has full support for Juicebox-Pro (and SimpleViewer-Pro) galleries and the galleries can be created within the application itself in a web browser interface (or created with JuiceboxBuilder and imported).

You can create Gallery Index pages and have as many galleries listed on each Gallery Index page as you wish.
Each gallery is represented by a thumbnail image with the gallery title displayed below and the gallery is opened when the user clicks on the image.
Demo sites created with Showkase can be found here and a sample Gallery Index page can be found here.

Showkase can also create non-gallery pages (About, Basic and Contact pages) where you can add information about yourself (or any other content you like).
All of this is done automatically within the Showkase interface without the need for any manual coding at all.

Showkase can be purchased as Showkase-Standard (which comes with Juicebox-Lite and SimpleViewer-Standard, the free versions) or Showkase-Pro (which comes with Juicebox-Pro and SimpleViewer-Pro).
The only difference between Showkase-Standard and Showkase-Pro is the bundled viewers.

More information on the differences between Juicebox and Showkase can be found in this forum post.

I hope this helps.

@wspollack

Yes, it would certainly be possible to create a template gallery and use this as a starting point for all subsequent galleries.
You could use the sample 'juicebox_pro_1.5.0/web/' gallery from the Juicebox-Pro v1.5.0 zip file, open its 'config.xml' file in a plain text editor, add the languageList you'd like to use (as an attribute to the opening <juiceboxgallery> tag) and save the file.

Now, when you want to create a new gallery, you can open this modified sample gallery in JuiceboxBuilder (instead of clicking the 'New Gallery...' button and starting completely from scratch), add whatever images you like, configure the gallery as required and when you save the gallery on the 'Publish' tab, the languageList will still be in place (alongside the gallery's other configuration options in its 'config.xml' file) even though it never appears in the JuiceboxBuilder interface.

When the user said "I have several galleries and i want all of them to use the same languageList definition.", my suggestion (to just add the languageList manually to all individual galleries) might still be the easiest solution for existing galleries.

However, your suggestion is an excellent idea for creating new galleries going forward.
Thank you for pointing it out.

I have run some tests and have found the following.

(1) Juicebox-Pro sets flickrTagMode to ALL by default. The Flickr API Explorer sets 'tag_mode' to 'any' by default.

(2) Juicebox-Pro sends 'original_format' as a Flickr API 'extra' parameter.

(3) Juicebox-Pro sets flickrImageCount to 50 by default (the same as the image limit within Juicebox-Lite). The Flickr API Explorer sets 'per_page' to '100' by default.

(4) The Juicebox-Pro flickrImageCount / Flickr API 'per-page' setting seems to make a difference to the image order.

#1 and #2 will likely not make a difference to your gallery but I notice that changing the flickrImageCount can affect the order of images.

For example, with the Juicebox-Pro flickrImageCount / Flickr API 'per-page' setting set to 500 (to cover all images in your Flickr selection), note the 4th and 5th images in the gallery / API results.
Now, reduce the Juicebox-Pro flickrImageCount / Flickr API 'per-page' setting set to 100 (less than the total number of Flickr images in your selection). The 4th and 5th images are still both present in the gallery / API results but their positions are swapped around (even though the sort order has not changed). Even though fewer images (100) will be returned by Flickr, I would expect the order of images in the 100 test to be the same as the order of these images within the 500 test but this does not seem to be the case (and only Flickr will be able to explain why as I do not know the algorithms that Flickr's API uses).

It should be noted that this happens in both Juicebox-Pro and with the Flickr API Explorer (independent of Juicebox-Pro).
When the Flickr API Explorer settings are identical to those used by Juicebox-Pro, the results are also identical.

If the order of images returned by Flickr (when flickrImageCount / Flickr API 'per-page' is set to less than the number of images you want to display in your gallery) is the order you'd like to use, then I'm not sure what you can do (as you'll need to set flickrImageCount to the number of images you want to display (which might result in an order you do not want).

The only thing I can think of is that maybe the images have similar but not identical time data (same day, same hour, maybe even same minute) and that Flickr's API builds an initial array of images images in different ways (depending on search criteria) and then sorts them by time but perhaps not going down to second or millisecond accuracy so some images with similar but not identical time data might end up in different orders. I do not know if this is what is happening (it seems unlikely) but it's the only thing I can think of at the moment which might explain the results I am seeing.

Maybe refreshing (editing or changing) the metadata stored within your images within the Flickr interface will result in more consistent and predictable behavior but Juicebox can only send a request to Flickr (via the Flickr API) and display whatever Flickr returns. It might be a long process but it might ultimately be the solution to the problem. (There is no way to know without trying.)

If you want to try to understand exactly why Flickr returns images in different orders depending on their API's 'per-page' value (even though the sort order does not change), then you will probably need to ask Flickr themselves in their API support forum.

I don't know if this will help but it's as much as I've been able to determine thought my own testing.

Unfortunately, there is no easy way to have multiple galleries share configuration options from a central location.
You'll just need to add the languageList option to each gallery's current list of options (see example above).

Thank you for the additional information.
It looks like a lot of images in conjunction with a deep directory structure is not an ideal combination.
Unfortunately, being that they are both platform limitations (rather than bugs specific to the JuiceboxBuilder code), there is little that we can do to eradicate them.
At least knowing that both of these issues cause problems, we can work around them (with a less deep directory structure and by adding small batches of images instead of one large batch).

Did you try adding all 100 images at once from the shallow directory structure (and, if so, did it work)?
There is a known issue which can occur when adding many images at once and if you are adding a large batch of images, the maximum path length might just be a red herring.

If you add many images at once, Adobe AIR may not be able to allocate enough memory for the task at hand. Even if your computer has plenty of free RAM, Adobe AIR applications are limited to around 1GB of memory allocation. The workaround is to add your images in smaller batches.

I don't know if this is relevant but it might be something to bear in mind when testing further.

It sounds like the problem is due to an underlying maximum path issue with either Windows 10 or Adobe AIR (the platform on which JuiceboxBuilder runs).
Either way, I think there is little that can be done (other than moving the images to a more shallow directory structure before feeding them to JuiceboxBuilder). I'm fairly certain that JuiceboxBuilder is not imposing a maximum path length itself.

Your testing sounds fairly conclusive: fails with a long path; works with a short path.

I've tried to replicate the problem myself but, strangely enough, have not been able to.
I created a directory structure as long as Windows 10 will allow (using the alphabet as a folder name and topping things off with a couple of digital at the end to max it out).

C:\abcdefghijklmnopqrstuvwxyz\abcdefghijklmnopqrstuvwxyz\abcdefghijklmnopqrstuvwxyz\abcdefghijklmnopqrstuvwxyz\abcdefghijklmnopqrstuvwxyz\abcdefghijklmnopqrstuvwxyz\abcdefghijklmnopqrstuvwxyz\abcdefghijklmnopqrstuvwxyz\abcdefghijklmnopqrstuvwxyz01

I then copied a few images to the 'abcdefghijklmnopqrstuvwxyz01' folder, added them to JuiceboxBuilder from this location and the application created the gallery successfully.

Even setting the Gallery Folder on the 'Publish' tab to be the long path above, I cannot get JuiceboxBuilder to crash (under Windows 10 Pro v1703 x64) even though it fails to create all the gallery files in the 'abcdefghijklmnopqrstuvwxyz01' folder.

I think the resolution to this problem is just to use shorter paths.
However, you might like to try removing the default maximum path length that Windows 10 imposes to see if this makes a difference.
It involves either modifying the registry or making a change in the group policy editor. Please see this web page for details.
Please note that I am not recommending that you do this. It is just a suggestion if you are comfortable making changes to your Windows 10 system via the registry or group policy.
Please note that if you choose to make any changes via the registry or group policy, you do so at your own risk.
I recommend that you just shorten your paths before using JuiceboxBuilder.

Incidentally, I have not made this change to my own PC. My tests above were carried out using the default Windows 10 maximum path length.
Also, I realise that the path you posted above is less than Window's default maximum path length of 260 characters but removing this limit might be worth a shot if you feel you want to try something.

@JoergWenzel

Are you saying that JuiceboxBuilder-Pro processes your PNG images when the the 'Resize Images' checkbox is deselected?
This should not happen (and it does not happen in my own installation).

I've just double-checked and, with the 'Resize Images' checkbox deselected, JuiceboxBuilder-Pro v1.5.0 just copies the source PNG files across to the gallery's 'images' folder (but with .jpg file extensions) with no processing or resizing at all.
The files in the gallery's 'images' folder are identical (byte-for-byte) to the source PNG files. (I've checked their SHA256 hashes.)

As long as both the 'Resize Images' and 'Use Watermark' checkboxes are deselected, the source images should be copied across to the gallery's 'images' folder untouched.

Please try again and make sure that you deselect the 'Resize Images' checkbox (like in your screenshot) and save the gallery to a new empty folder (to ensure that pre-existing files are not present in the gallery folder).

If you find that images are still being processed when the 'Resize Images' checkbox is deselected, then I cannot explain why but it might be wise to try uninstalling and then re-instaling JuiceboxBuilder-Pro to see if this makes a difference.

Thank you for providing the URL to your gallery's web page.

It looks like the problem is that there is not enough room in your gallery's caption area to display the Flickr descriptions along with the Flickr titles.

When setting captionPosition="BELOW_IMAGE" (as your gallery does), Juicebox uses the maxCaptionHeight value as the actual height of the caption area (rather than a maximum value). (This is noted in the short description for maxCaptionHeight in the Caption Options section of the Config Options page.)

Your gallery currently sets maxCaptionHeight to "50px" which is too short to accommodate both the Flickr titles and descriptions.
Increase maxCaptionHeight (perhaps to its default value of 120) and you should see the Flickr descriptions below the Flickr titles.
(Incidentally, the value for maxCaptionHeight should be just a numeric value, without the 'px' suffix.)

I hope this resolves your problem.