I'd love to see this module get a settings page where users can choose what languages to enable, and specify flag images.
I was about to start coding something myself when I got stuck wondering which road to take. So I thought I'd post here and get other people's opinion on the subject.

I've thought of 4 possible ways to do this:

1 - Batch
This is pretty much what this module currently provides, but with an interface for selecting a different folder (within the files directory) where the flag images are stored. Language codes and descriptions would be obtained from the flag filenames as per the current setup. A new version of the module I submitted provides this functionality: #592040: Code rewrite with semi-GUI interface

2 - Manual
This would be a settings page where users could create languages by entering a code, specifying a description, giving each language a weight (via Drupal's drag-and-drop interface), and specifying a flag location (or uploading a flag image). The only downside of this approach is that you'd have to add languages one at a time, not in a batch.

3 - Combination
This would be a combination of the 2 approaches above: for each flag in the specified folder, you'd be able to enter a description and weight. This means you just add your flags to the folder, then give them all descriptions and weights on the settings page (weight being the order in which the flags appear).

4 - Advanced
This, I think, would be the most advanced approach: you put lots of flag images in the folder then on the settings page specify which flags are enabled and disabled (again, providing descriptions, weights, etc.) This means that users can download a collection of flag images (or this module could ship with free ones) then just enable the ones you want via the settings page without having to add/remove flags from the folder. The same UI stuff applies here: for each enabled language you add a description, weight, etc.

I think possibly the 3rd option (combination) is the best approach... What do you think?

Comments

blinkingtwelve’s picture

blinkingtwelve commented

It would certainly add value to let users configure this module without them having to touch the filesystem. I can imagine setups where content admins don't even have access to the filesystem. Adding to that, multisite installations will become possible if all configuration is stored in the DB.

I think something like 4) would be best. With 3) you have to touch the filesystem to prevent flags from showing up, which defeats the benefits mentioned above.
We could have defaults for descriptions and weights coded into the filenames as they are now, which will mean that users can (sorta) easily transfer 'themes' to eachother just by zipping up a dir. Only overrides (weight, description) should be stored so it will work out of the box without 'themes' living in the DB.
As for the storage mechanism, I'd like to avoid this module having its own table. I think that simple key-value attrs should suffice. As for uploading files - I think this could nibble away dev efforts (added complexity and possible attack vectors), so let's not.
Maintaining a D5 port will most probably not be worth the effort.

Anonymous’s picture

Anonymous (not verified) commented

Sounds good! Some other thoughts:

- Maybe have this module ship with a few different flag types (FamFamFam, Icon Drawer, JFitz.com, etc.) then users can either choose one of these or choose 'Custom' to use their own imported collection...

- I wouldn't worry about having default weight and descriptions in the filenames, you'd more than likely have to edit each filename for any flag collections you want to ship with. Instead, just have hard-coded defaults for the different country codes (i.e. 'en' = English, 'es' = Spanish, etc.) As for weight, this'll just be the order they're in on the settings page, I wouldn't think you'd need defaults...

- If you did still want to support filenames, have the module use the filenames if they exist, otherwise (if the filenames are just the country codes) use default settings for each code.

I agree, I don't think a backport for D5 for this version would be needed.

blinkingtwelve’s picture

blinkingtwelve commented

@#1 - Nice, if licenses for those sets are GPL compatible.

@#2 - Yes that seems better (hardcoded defaults). Some folks do not have the right unicode gear.