removing admin translation files is a tedious job

[tbba]

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]

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

On Sun, Aug 17, 2014 at 5:47 AM, Carl notifications@github.com 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 100 times while paying attention not to remove anything else but
those admin language files.

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?

—
Reply to this email directly or view it on GitHub
#600.

[tbba]

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]

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]

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.

[tbba]

I close this discussion - if you don't mind - and move this to the forum.

[tbba]

visit: https://processwire.com/talk/topic/7310-admin-language-files-in-module/

[ryancramerdesign]

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.

On Sun, Aug 17, 2014 at 6:24 AM, Nico Knoll notifications@github.com
wrote:

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

Maybe that's something for 2.6.

—
Reply to this email directly or view it on GitHub
#600 (comment)
.