the design problem of Lychee Photo Gallery

[ttys3]

Lychee is a very easy-to-use photo gallery. simple but beautiful.

However, it does have some design problems

problem 1: user uploaded filename should not randomized or got obfucated. when the file leaves the Lychee app, it should be remaining meaningful, not something like unix timestamp or md5 hash you never know what this file do. a file named dog.jpg is more meaningful than a file named 06d80eb0c50b49a509b49f2424e8c805.jpg

problem 2: source file should not treated like thumbnail in the same level.
source file should put in standalone directory. while thumbnail should generated under a dot directory like .lychee-thumb

problem 3: the photo importing feature, which is totally wrong designed
while most usage case is, a user who has lot's of photos on a NAS, the Lychee app should not copy or delete the source file, it should only record the file path and insert it into DB. and then generate the required thumbnails. users who may have TB level photos, if copy again, it will be a lot of space waste and may encounter on performance problem.

Lychee should take Synology Photo Station or Synology Moments as a good example

https://demo.synology.com/en-global

[ttys3]

enhancement:

相册功能重新设计

1. 相册名就是目录名，相册层级关系，就是目录层级关系。

2. 删除相册，就是删除目录及其下所有文件

3. 自动相册创建。当相册根目录下有新目录创建，并且有新文件添加时，新相册就自动创建了，相册名就是目录名。

导入功能重新设计

0. 用户选择相册，或直接使用当前位置的相册。

1. 用户选择NAS上的图片源目录(实际上是经过dock volume映射过去的）

2. lychee扫描源目录所有图片

3. lychee将源目录图片入库，并生成中图和小图. 源图片路径保持不变，lychee只记录源图片路径。

中图和小图统一放在lychee的.lychee_thumb 目录下， 缩略图路径与源目录路径保持映射关系， 也就是说，不依赖数据库，根据源文件路径，可以计算出缩略图的路径。

上传功能重新设计

0. 用户选择相册，或直接使用当前位置的相册。

1. 用户选并上传本地电脑的图片到lychee

2. lychee将源目录图片入库，并生成中图和小图. 源图片路径为相册所在的目录，文件名不应该被修改成随机字符，因为随机字符意味了这个文件离开了这个系统，连鬼都不知道这个文件是干嘛的。
   中图和小图统一放在lychee的.lychee_thumb 目录下， 缩略图路径与源路径保持映射关系。

[ildyria]

problem 1: user uploaded filename should not randomized or got obfucated. when the file leaves the Lychee app, it should be remaining meaningful, not something like unix timestamp or md5 hash you never know what this file do. a file named dog.jpg is more meaningful than a file named 06d80eb0c50b49a509b49f2424e8c805.jpg

While I see the attractiveness of such, I would say it makes managing duplicates harder.
If the files names need to be recovered, it can be simply done by downloading the album (which I agree, is not the most convenient way).

problem 2: source file should not treated like thumbnail in the same level.
source file should put in standalone directory. while thumbnail should generated under a dot directory like .lychee-thumb

This is already the case. Sources are in big. The thumbnails and lower resolutions ones are respectively in thumbs, small and medium.

problem 3: the photo importing feature, which is totally wrong designed
while most usage case is, a user who has lot's of photos on a NAS, the Lychee app should not copy or delete the source file, it should only record the file path and insert it into DB. and then generate the required thumbnails. users who may have TB level photos, if copy again, it will be a lot of space waste and may encounter on performance problem.

This has already been solved. The command line ./artisan lychee:sync creates a symlink instead of making a copy of the picture (if I am not mistaken).

Lychee should take Synology Photo Station or Synology Moments as a good example

https://demo.synology.com/en-global

Will check it out.

[ttys3]

This is already the case. Sources are in big. The thumbnails and lower resolutions ones are respectively in thumbs, small and medium.

users may nerver care about what is 'big', what is 'small'. the only thing care is the original photo file.
as for thumbs, small and medium, it should not in the save level directory as big.
also, there should not exists a directory named big, if the user uses a file browser, all files user should see is only the big one.

although, the Lychee may show the user thumbnail, but this is an internal file format, all thumbnails,
small and medium etc.. , should be internal, should put under dot directory, this is what I mean.

thumbnails may generated dynamiclly, if needed. or use a cron job. no need to generate the same time the file uploading. and ,it can be purged or cleared safety. this is what I mean "source file should not treated like thumbnail in the same level."

[ttys3]

This has already been solved. The command line ./artisan lychee:sync creates a symlink instead of making a copy of the picture (if I am not mistaken).

a symlink is kind of workaround, I did not see this feature before, thanks for reminding.
but, I think symlink design is also wrong. because, with ,or without is, the photo can also accessed by Lychee. I prefer the cloud native way, like use a docker volume mapping,
a directory under /mnt/mydriveA/photoA can mapped to /in-container-path/lychee/upload/photoA easyly, so, in this way, the Lychee even no need to import manully, it can run at background the scan his own root directory, just like Synology Photo Station will do the auto scan.

[ttys3]

While I see the attractiveness of such, I would say it makes managing duplicates harder.
If the files names need to be recovered, it can be simply done by downloading the album (which I agree, is not the most convenient way).

your take a approach which is friendly to programmers but not friendly to users and the data.

Synology Photo Station do take care of duplicated filenames. it has an auto rename strategy.

a file named foo.jpg exists, the app may rename the new one duplicated name to foo1.jpg or foo-yyyy-mm-dd-hh-mm.jpg, you may say that, does foo.jpg , foo1.jpg and foo2.jpg also meaningness ? yes , it is meaningness, because the user provides filename is originally meaningness, it is not the app's fault. if user have 5 file all named foo.jpg` under different direcoty,
he himself also do not know what the difference is .
app should not try to resolve the problem it can not resolve. so, this is totally not a problem.

[ttys3]

and also, I want to say, most of the framework, or application creators,
did multi lang (al maybe i18n) feature in the wrong way.

take Lychee for an example,
the translation file: https://github.com/LycheeOrg/Lychee/blob/master/resources/lang/en/validation.php

the key value format.

'digits_between' => 'The :attribute must be between :min and :max digits.',

in the PHP code, I guess it just use digits_between, but when you check the code,
do you realy under stand the whole sentence quilck when you have hundreds of , or thousands of translations?
No. you need to check the key => value defines again and again.

so far, I think the most convenient way is the old gettext way.

take vue for example:
this project is a good one:
https://github.com/Polyconseil/vue-gettext

#Extracting strings
make makemessages

# manual Translating message files
# ....

# Compiling translations
make translations

the point is:

1. the original text is the original English, not a key.
   and the translation texts can be extracted automatically by tools
   in frontend, the code may like:

<translate>Please enter your password to proceed:</translate>

you can see the total string: Please enter your password to proceed:

and in PHP world, the WordPress i18n support is a good example

but lot's of framework do invented their own wheels. although it maybe widely used.
but does not mean it do the right thing.

yeah, the implemtation is simple, and it does do the job,
but doing the translation job will get you crazy.

2. it has many gui tools to do the translation, no need to edit a key => value file or even json file
   take poedit for an example https://poedit.net/features

---

this is not Lychee only, many project creators does not know what they are doing.
and just know to use something they think it is fasion, and did not like to take a look at
the old gettext way, maybe they think it is too old.

yes, filebrowser is also a bad example (json format key: value translation):
https://github.com/filebrowser/filebrowser/tree/master/frontend/src/i18n

[ttys3]

https://translation.io/blog/gettext-is-better-than-rails-i18n

[ildyria]

Don't get me wrong, but we are not against changing the translation interface. :)