General modularity downside

automatthias

Vanilla's modularity is brilliant. It's very easy to download and activate an extension. However, there's no way to ensure that any two extensions will work together. I've experienced conflicts between Friendly URLs and Search Saving. Also the quoting and formatting extensions don't ensure that the quotations are handled correctly: that if an experienced user chooses text formatter and html quoting, the HTML isn't interpreted. Extension translation is another problem. Every extension needs it's definitions to be cut & pasted into the languages/LanguageName.php file, which effectively flaws the download-and-activate extension beauty. Do you think that there could be a general solution? Or at least a way to display a warning that some extensions are in conflict?

Minisweeper

I think the main thing is to setup a standard protocol for extension developers. The way to put definitions into extensions and still have them translateable will always be difficult to work out the best way (either in language or extension files or something different?) I dont think it's a downside as such, it just needs some detailed thought and, to be brutally honest, some trial and error before the best solution is to be found. I think there could be a major part for a central server which talks with vanilla directly in certain instances; but again, it's tough to work out the best way.

Mark

Extension conflicts happen in every program that allows them. The only thing that can be done is that the issues be brought up with the extension authors and a resolution be found.

garymardell

Don't suppose there is anyway for the software to search as it were for these conflicts and provides a warning before install? Such as something using the same variables (i dnt know)

Mark

Not really, no.

One strange thing is, however, I've got friendly urls and search saving enabled on here, and they work together perfectly...

automatthias

What about translations? Can you think of some way to circumvent the need to embed the translation into the extension code? Each extension could have its language file, for example: extensions/ExtensionOne/default.php extensions/ExtensionOne/English.php extensions/ExtensionOne/Polish.php extensions/ExtensionTwo/default.php extensions/ExtensionTwo/English.php extensions/ExtensionTwo/Polish.php (...) In this scenario, the translation files would belong to the translation package, although they'd reside inside extension directories.

Minisweeper

The only difference between that idea and the way most extensions do it now is it's in a different file. The extension still needs translating seperately to the translation of the rest of the system and then either including in the package or being made available somewhere. I'd consider the best way would be to have language/English/extensionname.php contain all definitions for the extension. Then if it gets translated that translation file goes into the addons repository and is put into the lanuage/LANGUAGENAME/extensionname.php if you get me. Whatever you do in theory the extension and its translation need to be bundled seperately but linked somehow. If you bundle an extension with all the available translations for it you're wasting space that way, and if you bundle a translation with translations for all the extensions aswell you're wasting space unless you use all the extensions. This is part of the reason i suggested making an extension system which allowed the user to search for an extension through a gateway on their vanilla forum, choose it, then have vanilla grab the extension and all necessary files from the repository and pull them onto the local system and install it. But Mark has done it his way for perfectly valid reasons i'm sure.

automatthias

So the issue is how to place the cartesian product of all the languages and all the extensions that display any text. You can do it either:
/LANGUAGE/EXTENSION/
or
/EXTENSION/LANGUAGE/
which doesn't really make much difference. The point is to have separate files for each language-extension combination and do not mess with the main translation file.

As for bundling, I believe that having all the translations bundled into the extension is acceptable. You say it's waste of space, but I say the space is cheap and time is expensive. I'd rather sacrifice few hundreds if kilobytes on the server than my time spent looking for the translation file, downloading it separately and installing. If somebody values space more than time, she/he can always spend time deleting unnecessary files.

jakob_r

I started a similar thread on the vanilladev forum. There were voices for both ways. I felt that bundling translations strings in the extension itself was easy enough and you simply comment out the languages you don't need. My feeling was that everything pertaining to the extension stays with it.

However, with the user-definable "change language" add-on, 'hard-commenting' the language strings would mean languages don't change for add-ons. If the language strings are in the main language/defintions.php, then it would work, but only if the english-language strings are commented out in the extension (or these override any other definitions). That would imply moving the english-language add-on strings to the english/definitions.php, and that's probably a nightmare to manage.

I think this needs more thought. Perhaps the add-ons could include the language-strings in the extension itself and test for the current language, else use English (also test for personal overrides in conf/languages.php file first). So that one doesn't have to test for each language, perhaps the language strings variables get a language prefix, and add-ons test to see if the prefix matches the current language setting (or xml lang def). That way it would remain extensible for new languages. Translation authors would just have to make sure that the vanilla language setting or the xml lang def and the language string prefixes match. Just a suggestion.

Minisweeper

It'd seem to me to be easier to have a LANGUAGENAME.php file per extension than putting the definitions into the extension itself and potentially having a load of definitions at the top of the extension file which say the same thing in 3 different languages and 2/3 of which need commenting out (or choosing through yet another variable)
If the extension just included the language file of the same name as the one the forum itself is using (or default to english otherwise) wouldnt that make life slightly easier?

If we were to stick with the 'must copy extension defintions into main defintions.php file' i do think that should be a system managed and not a user managed thing. Asking people to copy and paste stuff into different places as part of the installation process is a no go in my opinion. For better or worse i believe it should be possible for the user to dump all the vanilla files into a dir on the server, set permissions and necessary, and forget that FTP ever exists (i did have a theory whereby the user uploaded a single file to their server and part of the install script was to grab the remaining files from the repository but that's really not necessary)

And yeah automatthias, the reason i suggested bundling was working on the basis that translators and extension makers wernt the same people, and it wouldnt always be possible (in the short term) to get the extension creator to add a translated file into their extension zip and re-upload it as soon as a translation was finished. Perhaps the neatest way (alas also the most complex for mark) would be to let translators upload their translations to the addons dir and attach them to an extension - then when people downloaded the extension the addon dir asked which language you wanted it in and gave you both the files for download (or a zip of both the files).

It's difficult for me to keep suggesting stuff when i have no means of even attempting to put it into practice (particularly at the moment when i have much more important things to worry about than learning OOPhp)

On a slightly different strand (though i really shouldnt get into it now we're in the heart of working through the language issues - and as mark says there will always be conflicts with extensionisable software) - another issue to consider is how extensions can be made to work with each other but not rely on each other - i just remembered the bug there is with the cleanup extension as present which means it tries to clean out the clipboard for users it's deleting but fails if the clipboard hasnt been installed. In such a case the extension needs to know not to try but it still needs to do it if the clipboard had been installed.

I suppose really what we're getting into is the addition of delegates or hooks into extensions like they've been inserted into the core. But that really relies on good practice by the extension developers.

_jameshales

Perhaps extensions could be designed so that the different functions inside of them can be switched on and off, and the order of execution of each function can be switched around, i.e. so that one particular function of extension A is ran just before extension B runs, to prevent conflict. The system for this could be so designed that configurations can easily be imported via a set of conditions, which detect the extensions present and switch functions around and turn things on and off, to solve problems. Because extension developers are unable to test their extension to work with all the extensions that could possibly exist, a cooperative repository of conditions or solutions could exist online, so that one can easily find fixes to extension conflicts. If it is impossible to resolve conflicts this way, then replacement functions for particular extensions can be written to solve the conflicts.

jakob_r

Mini, yes, the extra language string file in the extension directory would work too, and would make it possible for translation authors to upload it separately to the add-ons directory. But, as you say, more work for mark and possibly more version incompatability problems to cope with (which language file for which extension version). But it *would* make forum user-choosable languages possible.

Dinoboff

Why not add the default language string in default.php of the extension (here, the name of this extension is "extension") like that// if definitions of "Extension" version1 are not translated in language package // Set these default definitions if (!array_key_exists('EXTENSION_VERSION1_TRANSLATED', $Configuration)) { $Context->Dictionary['ExtensionString1] = "String1"; $Context->Dictionary['ExtensionString2] = "String2"; ... } // if definitions of "Extension" added in version1.1 are not in translated in language package // Set these default definitions if (!array_key_exists('EXTENSION_VERSION1.1_TRANSLATED', $Configuration)) { $Context->Dictionary['ExtensionString10] = "String10"; };
And the translator (here, a french one) would just have to update his langage package that way:// Definitions d' "Extension" version 1 traduites $Context->Configuration[EXTENSION_VERSION1_TRANSLATED] = 1; // Definitions d' "Extension" ajoute dans la version 1.1 traduites $Context->Configuration[EXTENSION_VERSION1.1_TRANSLATED] = 1; // Definitions pour "Extension" $Context->Dictionary['ExtensionString1] = "Chaine1"; $Context->Dictionary['ExtensionString2] = "Chaine2"; ... Context->Dictionary['ExtensionString10] = "Chaine10";

ichigo

for the sake of easy plugin installation in terms of just plug and play.. i hope we wont have to install the extension in one location (/extensions) and the language definitions of the extensions to another place. that just complicates things..

and you know what that means ->

* it is no longer that simple (vanilla is awesome because of its simplicity)
* people are more likely to make mistakes
* more need for support

this might sound a bit exaggerated but i think it is true. not every person who uses the board will be as experienced as the early adaptors. and eventually there are going to be more and more people who chose vanilla over other systems. complexity can become a supporting nightmare very fast.

i think the idea of putting a languages file into the folder of the certain extension is a good idea. though then the translation relies on the developer as he is the only one who can update the extension and therefore the only one who can update the language definition file inside the extension (which is still a better idea than providing extension and language definition seperately because of version conflicts)

how do other forum systems cope with that problem? or do they just dont mind?

is it possible to provide language definition files like "English", "Deutsch".. in the folder of the extension and make vanilla automatically chose the langauge definition file which has the same name as the current default language of the forum? and if it doesnt exist fall back to English or any other language definition that exists? well sounds a bit complicated and probably is. just random thinking here. i guess its a bad idea.

cheers

edit: Minisweeper's suggestion of adjusting the lussumo.com/addons system so that translators are able to provide translation files and translation file updates independent from the extension author is a very nice idea i think. that might really solve the problem of relying on the extension author.

Dinoboff

With my solution, authors of extensions just have add one line to their extensions, and tranlators can translate extensions without mark having to change the way to vanilla work.

Max_B

Where are we by now?
As I need the ability for vanilla to switch language on per user basis, I must choose between Dinoboff solution and balti's one, as suggested in the thread started by jacob_r : http://lussumo.com/vanilladev/discussion/54/#Item_4

Dibonoff's does not modify core files, balti's has the advantage of a more structured way opening for translation of extension definition as well (http://lussumo.com/vanilladev/discussion/140/)

To cope with the location of translation files, what about a simple include from the main language_name/definitions.php of all extensions/*/language_name.php

I'm setting all my stuff in an SVN tree to be able to follow future direction but I'd like to know if we (Mark) have a favourite way.

Dinoboff

I havn't read the balti solution when I had this idea. His solution is great, because that doesn't change the way Vanilla works, that is just a new methode. Old extensions are still working.

I am not sure Mark have read the post of Balti. Would be a good idea to ask him before he release vanilla 1.0.1

Max_B

I checked out 1.0.1 two days ago in the "vendor" branche of my own repository, and, AFAICT, the balti's suggestion is not in, yet.

Dinoboff

It has been added:// Can be used by extensions to define new definitions. This way, if a // translation exists in the translation file, the definition in the // extension will not override it. function SetDefinition($Code, $Definition) { if (!array_key_exists($Code, $this->Dictionary)) { $this->Dictionary[$Code] = $Definition; } }

Mark

Can be used by extensions to define new definitions.

Man, what a bad sentence. I've got to change that.

Max_B

Tanks Dinoboff, I see that you have a direct link to The Architect, or his SVN passwd.