This is based on my own experience of running Gallery and a work in progress. YMMV. Feel free to comment on the discussion page.
Gx prioritized feature list
- Migration from G2. It is very important to have an upgrade path for existing G2 users. A lot of time has been invested in adding image/album metadata and this should be preserved.
- Mass and recursive edits of all metadata. There are few things more frustrating than being forced to repeat the same operation over and over again.
- Automatic rotation of photos based on EXIF orientation data.
- In-place edit of common (tags, title, caption, description), if not all, photo meta data.
- In-place rotation of photos (one or two clicks max). Either always show small rotation buttons on the image in its corners on mouse hover (one click), or activate an "edit mode" first and then rotate (two clicks).
- Tag support, filter/search by tags. Make this thing intelligent: when in place editing tags, show other tags used in current album, and/or common tags from the entire gallery. Allow the user to click on these and tag without using the keyboard.
- Meta data search. If there is good tag support, a simple search accross title, caption, description is enough for me.
- Scale down enormous images on the client. If a visitor is viewing a single image that does not fit in the browser window (typically the full-size image), scale it down so the entire thing is visible by default. Provide an option to show the image with no scaling or even allow zooming in and out of selected areas.
- Graphical distinction between photos and albums (image frames). I like setting an image frame for albums and that's the only use I have for them.
- Complete self-update (downloadable plugins), including the core.
- Support a single, simple method of uploading images. Choose the one that is most widely used (do we have statistics on this?). Leave the rest out of the core product.
- Friendly URLs everywhere.
- Simple permissions and user accounts. I don't care much for user sign-up, but the administrator should be able to restrict viewing and editing of certain albums to certain users. As far as I'm concerned, it is enough for permissions to only be album level.
- Blocks. Should be able to be embedded into external pages.
- Administrative dashboard. Provide a few simple statistics out of the box (e.g. disk space usage, number of photos/albums) and provide hooks for plugins to be able to display stuff here, such as activity logs, latest comments, errors, etc. Link to the readme, GMC, Codex, forums. Perhaps show important news, such as a new version or security update, though this probably has privacy issues.
- Don't need any support for text, MP3, video, lions and tigers.
Strings and localization
Since we'll be starting development from the ground up, I'd like to share my thoughts on revising the string writing guidelines. The current version can be found at http://codex.galleryproject.org/Gallery2:Coding_Guidelines#Strings.2FTexts_and_Translation.
I'd like them to be extended. They should be treated as coding standards for code. Strings should look the same regardless of which developer writes them. I mention this because there are currently several types of inconsistencies that are visible in the product as a result of a lack of standardization. Some examples:
- Different methods of linking (%slink%s, <a href="example.com>%s</a>, etc.). This has mostly been eliminated.
- Some error messages are properly capitalized and end with a punctuation mark, some do not ("this is some message" vs "This is some message.").
- Some developers write sentences with double spaces between them, others do not.
- Some error messages are more verbose, others less.
- There are more, I just can't remember now.
More important than the above are translation difficulties that are inadvertently being introduced. Not all developers are equally familiar with the problems of localization, so it would be good to document the most common problems and how to avoid them. Examples:
- The same string should never ever be sent to gettext twice. The most common example from Gallery is when a page title is used as an imperative action description on a button. An example from the core module is the "Login" string. It is used as the title of a link to get to the login page, and as the text on the button that logs the user in. In many (most?) languages the words for these two strings are different. If they're gettexted twice, they only show up once in the .po file, and the translator cannot choose the correct word for each instance of its usage. The translation ends up being inaccurate and/or funny looking.
- Never write strings like "There are %d photo(s).", for obvious reasons. I don't remember seeing this in Gallery, but still it should be in the guidelines for third-party developers.
- Never break up sentences. I haven't seen this in Gallery either.
If all developers write strings according to a common set of rules, translations will end up being more accurate and inconsistencies will be eliminated. As a result, the product will end up looking more polished and professional. Once the guidelines are in place, the time impact on development will be negligible.
