Admin language files in module

[ceberlin]

(This discussion is moved here from the GitHub issues board)

The discussion ended by considering of moving the admin language files to a module (maybe even aware if the translations are for the regular version or the DEV version of ProcessWire).

You comments and ideas are highly appreciated!

---

DISCUSSION SUMMARY FROM GITHUB:

tbba (ceberlin)  wrote

Today I had the honour to remove admin language translation files from the default language to have that back to English. That ment clicking the trashcan a 500 times while paying attention not to remove anything else but those admin language files. (Well I ended up doing this in the database directly as a workaround.)

For the Wishlist:

Why not adding a button where all instance that start with "wire--" have the trashcan seleced automatically.

Or better: I would prefer at least to have them in a separate repeater list so that I find my own frontend translations and those settings by site--modules like supersmartypans easier.

Or even better: why not separating Admin translation files to a module somehow so that installing/de-installiing, updating(via ModulesManager!) and switching them on and off is much easier?

 

 ryancramerdesign commented 

Double click the trash can and it'll mark them all for deletion.

 

tbba (ceberlin)  commented

Thats cool. I did not know that. There is still the possibility of deleting too much (site-- stuff).

What about the idea to separate the site-- files from the wire-- files? Wouldn't that be much easier?

EDIT: And a module for the wire files would make the updates over the modules manager so easy. No more dropping of tons of files - and alerts when they are outdated.

NicoKnoll commented 

I think it probably really makes more sense to change language packages to modules which are requiring "Language Support" to be installed.

Pros:

• easy updatable
• makes my module "LanguageInstantInstall" obsolet because you just could list al of the languages which are in the module directory with "module manager"
• It's more the ProcessWire way of being modular

Cons:

• How to add custom translations for e.g. modules?

Maybe that's something for 2.6.

tbba (ceberlin) commented

A module would have another advantage:

There could be something implemented that matches the translations to the PW version.

Right now, using the DEV version could mean: not matching translations.

But - thinking loud - there could be a DEV version of the language files on GIT 
that then matches with the PW DEV version - and the module selects the right one.

 ryancramerdesign commented 

I agree, language packs as modules would be nice for the future. Like Carl mentioned in splitting site and wire files, perhaps language pack modules would be for wire, and the existing storage system could be exclusively for site.

[ceberlin]

@ nico ( "How to add custom translations for e.g. modules?")

That is a really good question and maybe another reason for a module.

What about the possibility to put individual files to the LANGUAGES (copied by the click of the mouse over from the module) which overwrite the standards so that you can maintain individual translations if needed. 

Advantages:

• your individual strings would survive language updates from the module - that eliminates the risk of updating languages
• the number of files that need individual treatment are probably not so many (opposed to the 500+ files right now) 

(This all is a loud thinking - not a finished concept yet)