Enhance: add module/package install/uninstall event by SlySven · Pull Request #900 · Mudlet/Mudlet

SlySven · 2017-04-16T00:32:34Z

This was one item inspired by the work of the coder(s) who forked Mudlet to something that could handle Utf-8 in some manner. It was something that struck me as potentially useful (they used it) but their implementation did not quite match up to how we structure things. The original only reported the installation or un-installation of a module or package in Host::installPackage(...) or Host::uninstallPackage(...) but as those methods are used in a number of manners it was remiss, I think, not to report the second argument to those methods which may have a bearing on the significance of them being run. Also the original appended the package or module name onto the end of the fixed event name meaning a separate event handler would have to be registered to capture the loading or unloading of each different package/module name concerned. I have revised the code so that a uniform "sysInstallPackageEvent" and "sysUninstallPackageEvent" is generated for all modules/packages that are changed, with the following arguments:

"sysInstallPackageEvent"
(string) package/module name
(number) nature of event:
- 0 - package
- 1 - module (via UI or normal profile loading)
- 2 - module (via a "sync" event from another profile)
- 3 - module (via a script)
(string) file name of package, archive file name for module

and:

"sysUninstallPackageEvent"
(string) package/module name
(number) nature of event:
- 0 - package
- 1 - module (via UI)
- 2 - module (via a "sync" event from another profile)
- 3 - module (via a script)

Signed-off-by: Stephen Lyons slysven@virginmedia.com

This was one item inspired by the work of the coder(s) who forked Mudlet to something that could handle Utf-8 in some manner. It was something that struck me as potentially useful (they used it) but their implementation did not quite match up to how we structure things. The original only reported the installation or un-installation of a module or package in Host::installPackage(...) or Host::uninstallPackage(...) but as those methods are used in a number of manners it was remiss, I think, not to report the second argument to those methods which may have a bearing on the significance of them being run. Also the original appended the package or module name onto the end of the fixed event name meaning a separate event handler would have to be registered to capture the loading or unloading of each different package/module name concerned. I have revised the code so that a uniform "sysInstallPackageEvent" and "sysUninstallPackageEvent" is generated for all modules/packages that are changed, with the following arguments: * "sysInstallPackageEvent" * (string) package/module name * (number) nature of event: * 0 - package * 1 - module (via UI or normal profile loading) * 2 - module (via a "sync" event from another profile) * 3 - module (via a script) * (string) file name of package, archive file name for module * "sysUninstallPackageEvent" * (string) package/module name * (number) nature of event: * 0 - package * 1 - module (via UI) * 2 - module (via a "sync" event from another profile) * 3 - module (via a script) Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

SlySven · 2017-04-16T00:38:04Z

Some sample examples using a module I cooked up to handle these events (installed and set with the lowest priority so it was the first module loaded!) which monitored my installation of an upgraded run-lua-code package (I tweaked it to report the error messages that we now sometimes return alongside a primary nil result from our Mudlet provided Lua functions):

vadi2 · 2017-04-16T05:17:53Z

Tagging @keneanung as well as this falls across @Mudlet/lua-interface.

vadi2

Thanks so much for adding this! It has actually been a long-standing pain point that you can't show a help menu when the package is installed or do any sort of cleanup when it's uninstalled!

Technically, I've tested it and it works as advertised. Just have a few of the fluffy issues to agree upon:

vadi2 · 2017-04-16T05:21:46Z

src/Host.cpp

    // reorder permanent and temporary triggers: perm first, temp second
    mTriggerUnit.reorderTriggersAfterPackageImport();
+
+    // This event was inspired by "Zoilder" in a Mudlet derivative in 2015


I don't think this historical information is necessary to have in the source code - and there have been long-standing feature requests already #685 and #741 that you're covering off with this :)

Well it was an acknowledgement of the source material which we cannot include in the Copyrights at the top because we do not have the full details...

Wasn't aware of the other requests but that is good to know - just thought it would be wanted at least by the originator and could encourage them to come to the source in the future.

We can mention that in the git commit for sure.

Do you still want me to take out these comments, I'd prefer to leave them, as I said, as the record of where they came from. (It would be likely that there are more to come as we try and reverse engineer what Zoilder has done - especially as I think there are one or two imperfections or limitations in their work!)

Yes please - git history should record the history, not the source code. Move this to the commit message please :)

vadi2 · 2017-04-16T05:23:03Z

src/Host.cpp

+    // * the original package filename
+    //
+    // The originators comment was (ES):
+    // Se ejecuta el evento que indica que se ha instalado el paquete.


Don't need to have any of the original comments, adds no value. The event is pretty self-explanatory.

Yeah, I'm sort of 'over' having comments or variable names or anything really that's not in English. I mean, I'm an inclusive fellow, but I'd like to consistently have only one language.

Well there are still some German ones (variables AND comments) from Heiko but it wouldn't feel right to rip those out without due consideration...

They need to be translated to English.

The only thing keeping some of those things in German is b/c we have nfc what they exactly mean 😄

We've got a German onboard the crew now, @keneanung. We've got hope

Actually http://translate.google.com does actually make some sense of those Germanic notes...! 😁

vadi2 · 2017-04-16T05:23:43Z

src/Host.cpp

+    // Thus the package itself can auto-initialize without having to reopen the
+    // session.
+    TEvent installEvent;
+    installEvent.mArgumentList.append( tr( "sysInstallPackageEvent", "This string may not want/need to be translated" ) );


Remind me - why wrap it in tr so it shows up for translators when they don't need to translate it but with a message not to translate it? Wouldn't it make more sense just not to expose it to them to begin with?

Event names shouldn't be translated since it would split the ecosystem in terms of lua code.

In hindsight I can understand that - will switch to QStringLiteral instead...

vadi2 · 2017-04-16T05:28:02Z

src/Host.cpp

+    installEvent.mArgumentTypeList.append( ARGUMENT_TYPE_STRING );
+    installEvent.mArgumentList.append( packageName );
+    installEvent.mArgumentTypeList.append( ARGUMENT_TYPE_STRING );
+    installEvent.mArgumentList.append( QString::number( module ) );


I understand where you're going with numbers - for the i18n focus - however between a number that's meaningless to everybody, even foreign users, and a word that is meaningful to somebody, that is our entire current userbase - and parts of the future userbase, because let's face it, if you're on the Internet, you'll be picking up a few written English words here and there - I think we should go with English words.

I don't think any human will be happy to deal with a nonsensical API that is all numbers at the end of the day versus words which at least look more different visually from one another.

I've already had to deal with this in the early versions of the exists API and it was not fun to have an exit map translating non-sensical numbers to meaningful names all over the place. It was really unpleasant to work with.

Tagging some of our international users/experts @JorMox @Garagoth @keneanung for opinions on this, happy to be swayed if others think it's the best.

I'm not even totally sure about the numbers, I think I have worked out what the values mean but it would be helpful to get confirmation from @Chris7 who's baby they are. I think it is necessary to provide them because the different usages of these two methods in various parts of the code (and them even calling each other) means the modelling of package/module installation and removal may be more complex than it initially seems...

I meant that we should not have the numbers at all - we should be using human words that at least some humans (most right now and in the near future) can understand.

I don't think using English words is a big issue for i18n. As @vadi2 said, in present day internet everybody is exposed to English. If this becomes a big issue, we can always implement a localization mapping to translate the English words.

Also, @vadi2, I am Eckol in Reinos de Leyenda, in case you want to tag me for i18n discussions.

Well, English words instead of numbers are much more readable - and serve partly as comment at the same time. Everyone writing any code is now familiar with English words enough.
All numbers will require commenting their meaning in all scripts later if authors want them to be readable to anyone else.
Also, string constants should NOT be translated or most scripts will stop working once Mudlet runs with different locale, which is stupid.

vadi2 · 2017-04-16T05:28:29Z

src/Host.cpp

+
+    // Like "sysInstallPackageEvent" this was inspired by Zoilder (2015)
+    // Their original comment was (ES):
+    // Se ejecuta el evento que indica que se va a desinstalar el paquete.


Same thing as above

…lation Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

Chris7 · 2017-04-16T17:59:31Z

src/Host.cpp

+    installEvent.mArgumentTypeList.append( ARGUMENT_TYPE_STRING );
+    installEvent.mArgumentList.append( packageName );
+    installEvent.mArgumentTypeList.append( ARGUMENT_TYPE_STRING );
+    installEvent.mArgumentList.append( QString::number( module ) );


Since there is no user exposure at this point, I think you should just make a mapping to the values of 0->3 to give users more informative names:
0 -> Package Install
1 -> Module Install from UI
2 -> Module Sync
3 -> Module Install via script

What granularity you want is up to you -- ie 1/3 might be combined to Module Install and 2 Module Sync

👋 @Chris7 - good to see you!

Checking the source I see that the use of those values 0 to 3 is as stated - and I think package/module writers may want to be aware of the differences between them as it could influence the behaviour they want to take if the package/module being added/removed is something they are concerned with. For instance one module could be installing another itself - so would expect to see a "3" type install happening and would not expect to have to handle it specially; but if it saw the same module with a "1" it would know that either the system is being started up or the user has just added the interesting module themselves...

As for "naming" the type of the event, to be honest from what scripting I have done number codes are quite usable and (for a small range of numbers) they ARE easier to translate at least in those parts of the world using "Western Arabic" numerals 😀

I actually don't care that much about numbers vs words, I was more pointing out that there was no legacy exposure of these numbers to users so any choice could be made. I actually think that this is symptomatic of a bad design in shoving everything into one event. I think having sys PackageInstall, sysModuleInstall, etc is the correct thing to do instead of cramming everything here

You make a fair point, that would actually be better.

ahmedcharles · 2017-04-16T21:54:53Z

src/Host.cpp

    // reopen the session.
    TEvent uninstallEvent;
-    uninstallEvent.mArgumentList.append( tr( "sysUninstallPackageEvent", "This string may not want/need to be translated" ) );
+    uninstallEvent.mArgumentList.append( QStringLiteral( "sysUninstallPackageEvent" ) );


Aren't we supposed to use the Latin1 version?

Yeah, I'm just reading up on 'em. One thing though, if you want to include some variable replacements QLatin1String does not have arg(...) methods - so you'd have to assemble such QStrings piece-by-piece but the % concatenation operator is superior to the + one (may need to #include <QStringBuilder>) apparently! 😮

These events were inspired by "Zoilder" in a Mudlet derivative in 2015 called MudletRL for the Spanish MUD whose website is at www.reinosdeleyenda.es For "sysInstallPackage" the original version appended the packageName and "Event" to "sysInstallPackage", but I have revised it to pass the packageName as a separate argument. Due to the range of circumstances in which this method can be called I have also included: * the invoking "module" argument in case it is necessary to differentiate the way in which the installPackage code is called - I think this could be a factor in some use cases that Zoilder would not have experienced in their usage. * the original package or module archive filename The originators comment was effectively (ES): «Se ejecuta el evento que indica que se ha instalado el paquete. Así el propio paquete puede auto-inicializarse sin tener que reabrir la sesión». which I think translates to (EN): "The event that indicates that the package is installed runs. Thus the package itself can auto-initialize without having to reopen the session." For "sysUninstallPackageEvent" things are largely the same except that there is no file name argument in the TEvent The original comment was effectively (ES): «Se ejecuta el evento que indica que se va a desinstalar el paquete. Así el propio paquete puede eliminar lo que necesite sin tener que reabrir la sesión». Which translates, I think, to (EN): "The event that indicates that the package is to be uninstalled is run. So the package itself can eliminate what you need without having to reopen the session." I have recently learned that it is preferable to use QLatin1String rather than QStringLiteral for QStrings that are not to be subjected to the translation process! Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

SlySven · 2017-04-16T23:20:35Z

Have taken comments (both English and Spanish) out of code. Have QLatin1Stringed the event names. For simplicity I propose that we keep the type as numbers 0 to 3.

vadi2 · 2017-04-17T04:51:06Z

I'd still like to get #900 (comment) resolved - Chris echoed my sentiments in #900 (comment) as well.

vadi2 · 2017-04-17T12:27:25Z

Got it, thanks. Appreciate your input here.

…

On Mon, 17 Apr 2017 2:26 pm ecam85, ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/Host.cpp <#900 (comment)>: > + // * the original package filename + // + // The originators comment was (ES): + // Se ejecuta el evento que indica que se ha instalado el paquete. + // Así el propio paquete puede auto-inicializarse sin tener que reabrir la + // sesión. + // which I think translates to (EN): + // The event that indicates that the package is installed runs. + // Thus the package itself can auto-initialize without having to reopen the + // session. + TEvent installEvent; + installEvent.mArgumentList.append( tr( "sysInstallPackageEvent", "This string may not want/need to be translated" ) ); + installEvent.mArgumentTypeList.append( ARGUMENT_TYPE_STRING ); + installEvent.mArgumentList.append( packageName ); + installEvent.mArgumentTypeList.append( ARGUMENT_TYPE_STRING ); + installEvent.mArgumentList.append( QString::number( module ) ); I don't think using English words is a big issue for i18n. As @vadi2 <https://github.com/vadi2> said, in present day internet everybody is exposed to English. If this becomes a big issue, we can always implement a localization mapping to translate the English words. Also, @vadi2 <https://github.com/vadi2>, I am Eckol in Reinos de Leyenda, in case you want to tag me for i18n discussions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#900 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGxjHp6TXMRa9llvgT9mwhKa3AnYijJks5rw1pXgaJpZM4M-gAM> .

SlySven · 2017-04-17T12:58:51Z

Ok, will plug in some fixed QLatin1String (:laughing:) strings, common to both events:

0: package
1: moduleUserOrSystem
2: moduleSync
3: moduleScript

OTOH I really think this is unnecessarily Anglo-centric and hard-coding string responses into stuff that users could be working with feels wrong to me. 😒

vadi2 · 2017-04-17T13:00:40Z

It'd be wrong if the international users were saying otherwise, but as it stands, feedback has been pretty consistent - translate the UI, add support for rendering other text and etc, but keep the API consistent in one language.

Chris7 · 2017-04-17T13:06:34Z

So here is what I predict/think should happen:

modules shouldn't be installed via installPackage. This was done b/c we used to commit changes by sending patches to Heiko so it was easier to tag along existing functions that have conflicts.
modules (and most of installPackage) should have a ton of things refactored out (in future commits), like unzipping, into their own functions
there should be separate module/package install functions.

I feel 3 should really happen, in which case you will have sysPackageInstall events being raised from installModule. I think it negates the i18n/numbers suck argument entirely by simply doing sysModuleInstalled, sysModuleUninstalled, sysModuleSync, sysPackageInstall, uiModuleInstall. This has the added benefit of dropping the payload for each event and making everyone's life simpler instead of if (toNumber(flag) == 3), etc. in lua scripts.

SlySven · 2017-04-17T15:58:38Z

Using an "event" system I think any event has to carry the complete data associated with that event else it has to carry some sort of identifier that an interested script then has to use to elucidate any further details about that event; this then makes for more work overall and counters the "make an event to tell other things about something"/"fire it off"/"forget" and then do not care if anyone else is actually listening or not attitude.

As I see it "Sub-classing" the sysInstallPackage and sysUninstallPackage events as proposed does provide one way of ensuring that an interested script/handler can make the choice of which events it wants to handle at the cost of checking which type it has got. The alternative is to provide a different name for each install/uninstall event type so that an interested script/handler may have to listen out for up to eight different ones rather than one or two...

Also wrap fixed strings in TEvent instances in QLatin1String(...) wrappers instead of prior QStringLiteral(...) as the former is more efficient for strings that ARE ASCII in origin. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

vadi2 · 2017-04-18T04:08:35Z

Right - subclassing events seems unnecessary like that, why not have it 'flat' and don't force the user to do even more filtering inside their event handler, when they can make Mudlet do it for them?

…t ones Following further discussions it was decided to avoid "sub-typing" the install and uninstall events depending on the cause and instead provide differently names ones to differentiate the initiation action. So we now have, for installation: * sysInstallPackageEvent - ANY package relate install * sysInstallModuleEvent - User interface or profile loaded module install * sysSyncInstallModuleEvent - Module reloaded because it was already loaded but it had been edited and updated from a DIFFERENT active profile, either via the "reloadModule(...)" lua command or from the "Save Profile" button in the other profiles's Editor. * sysLuaInstallModuleEvent - Module loaded via a Lua installModule(...) command in this profile. Similarly for removal: * sysUninstallPackageEvent - as above (includes during upgrading of a Server provided GUI) * sysUninstallModuleEvent * sysSyncUninstallModuleEvent - occurs before a corresponding install event * sysLuaUninstallModuleEvent Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

keneanung · 2017-04-18T19:03:10Z

Why do we differentiate between modules installed via script and and manually, but don't do the same for packages?

SlySven · 2017-04-18T21:25:40Z

Because modules can be updated on-the-fly - if they are edited in one profile and they are set to be "synced" (in the "Module manager") then each profile that "shares" that module will have it forcefully removed and replaced asynchronously when "Save profile" is hit in the editing profile - or by a profile that uses the "reloadModule( moduleName )" command.

Also, the concept of "Modules" I think was a later idea, to encapsulate a whole collection of different Mudlet item types and other resources. Packages, being limited to just one item type (and it's children) being selected in the Editor (and then "exported") are somewhat simpler beasties...

This is for scripts that don't care about the granularity of events.

vadi2 · 2017-04-19T05:52:00Z

I think what @keneanung was getting at is that there's an event for installModule() but none for installPackage(), but I think that's a limitation of the existing code that it doesn't differentiate? I think it's something we can let go for now, that's a really specific need and fixing that would blow up the scope of the PR.

I'm a fan of the API design - it also looks much clearer in the code, too. Just have two outstanding requests:

it's really good that we allow scripters to use mudlets event mechanism for filtering instead of foricng them to reinvent their own in code, though simple scripts just won't care about how they are installed - how about overarching "sysInstall" and an "sysUninstall" events that always fire? They won't have to contain detailed information of other events - "power scripts" can hook onto those individually if they need.
we have a mix "Event" suffix with and without right now: http://wiki.mudlet.org/w/Manual:Event_Engine and I'd be a fan of keeping them short instead of getting into unnecessary-long Java-like names. They're events already, they can't be anything else since they're in the event system that handles only events. It's like calling it an ATM machine, if you get what I mean?

I've submitted both changes in SlySven#2 PR for you. Happy to give it a green tick myself after that!

SlySven · 2017-04-19T13:32:16Z

Um, it might be redundant but the naming I was proposing was following existing tendencies, i.e. we have as I see it:

channel102Message
mapOpenEvent
sysConnectionEvent
sysDataSendRequest
sysDisconnectionEvent
sysDownloadError
sysDownloadDone
sysExitEvent
sysIrcMessage
sysLoadEvent
sysManualLocationSetEvent
sysMapDownloadEvent
sysProtocolDisabled
sysProtocolEnabled {this and predecessor added by later edit!}
sysTelnetEvent
sysWindowMousePressEvent
sysWindowMouseReleaseEvent
sysWindowResizeEvent

This isn't an exhaustive list (but I think it is likely to be at least 90%) of all system events as there are some with variable (variable with multiple meanings!) names associated with Atcp/Mxp I think. The sys...Event pattern is not universal but does have a majority here I think - and of course they (or the effects on existing user/module stuff using them) are fragile so we want to get something we are happy with first time... 😟

As I understand it, a handler function as written in the Script Editor will see the event it is processing as the first (string) argument that it receives - in that environment a string like "sysLoadEvent" does have meaning. I have seen by some recent work in another area (adding nil and boolean argument handling to "Labels") that the way things are put together can be different, is it possible that this is where the suffix "Event" may be seen as superfluous?

As a different matter: the original scheme of "sub-classing" the original install & uninstall event I proposed was to allow the user to "skip the details" - they only had to consider the type if they wanted to so we do seem to have gone from one position to its opposite. 😖

vadi2 · 2017-04-19T13:35:30Z

We didn't go from one position to the opposite - we went from forcing the user to reimplement event filtering in their Lua scripts to being able to rely on Mudlet to do the event filtering. Quite a difference and an improvement!

@keneanung what do you think on the event naming?

SlySven · 2017-04-19T13:43:25Z

Does "ignoring a provided function argument" count as "forcing the user to reimplement event filtering"? Am I missing something? Or was it that checking that argument for zero/non-zero necessary to tell the difference between package/module related events was objectionable? 😕

vadi2 · 2017-04-19T13:51:27Z

Yeah, it was the latter, but this problem is solved proposal for the granular and non-granular events.

Now what's just left outstanding is the event name - I see the Event suffix being redundant for events but I'm happy to compromise on this if the other @Mudlet/lua-interface member thinks it's fine.

keneanung · 2017-04-19T14:33:46Z

I'm with @vadi2 in that I'd get rid of the Event suffix.

vadi2 · 2017-04-19T14:38:41Z

I've coded up my proposal in SlySven#2 - merge if you agree and this'll be in 😉

This a great change all in all - finally packages will be able to show help / welcome menus upon being installed or do GUI cleanup before they are uninstalled.

Cut down on the redundancy in event names a bit

SlySven · 2017-04-19T15:33:07Z

Will need a bit of editing on the "rebase-and-merge" message to keep just the bits that made it through the process...

vadi2

👍

keneanung

Looks good to me as well 👍

SlySven · 2017-04-19T17:20:02Z

OH, b****r no chance to present a cleaned-up rewrite/actual summary of the changes - and in the absence of "merge" commits it is not obvious where this sequence of commits started (or ended). Humm, not so sure about the "rebase" method now... 😐

This is based on feedback we have collected at: Mudlet#900 http://forums.mudlet.org/viewtopic.php?f=7&t=19499

…evelopment (#900)

ahmedcharles · 2017-04-19T19:18:15Z

I made it look as if you merged your branch (after rebasing it, obviously). I personally don't mind this look since the lines don't end up crossing.

And I didn't know that GitHub censored comments?

Note: Knowing what the button does before pressing it is important.

The merge button creates a merge commit, by effectively doing:

git checkout development
git merge --no-ff <pr-branch> -m "<commit message>"

The squash option does a merge, but with the --squash, option:

git checkout development
git merge --squash <pr-branch> -m "<a commit message you get to edit>"

The rebase option does a rebase, by effectively doing:

git checkout <pr-branch>
git rebase development
git checkout development
git reset --hard <pr-branch>

So, if you want to squash, you need to pick the squash option.

* Added internalisation do's and dont's This is based on feedback we have collected at: #900 http://forums.mudlet.org/viewtopic.php?f=7&t=19499 #926

SlySven requested review from ahmedcharles and vadi2 April 16, 2017 00:32

SlySven self-assigned this Apr 16, 2017

SlySven added the 1 - Ready label Apr 16, 2017

vadi2 requested a review from keneanung April 16, 2017 05:17

vadi2 requested changes Apr 16, 2017

View reviewed changes

Revise: take event names out of the pool of QStrings liable for trans…

8239068

…lation Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

Chris7 reviewed Apr 16, 2017

View reviewed changes

ahmedcharles reviewed Apr 16, 2017

View reviewed changes

SlySven mentioned this pull request Apr 16, 2017

Revise: clean up some TEvent related stuff #911

Closed

SlySven mentioned this pull request Apr 16, 2017

Replace QStringLiteral with QLatin1String where UTF-8 is not needed #907

Closed

vadi2 added 2 commits April 19, 2017 07:31

Cut down on the redundancy in event names a bit

1f5c332

Added a plain install/uninstall events

503740a

This is for scripts that don't care about the granularity of events.

Merge pull request #2 from vadi2/more-consise-event-names

81f8863

Cut down on the redundancy in event names a bit

vadi2 approved these changes Apr 19, 2017

View reviewed changes

keneanung approved these changes Apr 19, 2017

View reviewed changes

SlySven merged commit 2f32ee4 into Mudlet:development Apr 19, 2017

vadi2 added a commit to vadi2/Mudlet that referenced this pull request Apr 19, 2017

Added internalisation do's and don't

cebfdb0

This is based on feedback we have collected at: Mudlet#900 http://forums.mudlet.org/viewtopic.php?f=7&t=19499

vadi2 mentioned this pull request Apr 19, 2017

Added internalisation do's and don't #927

Merged

ahmedcharles added a commit that referenced this pull request Apr 19, 2017

Merge branch 'SlySven/Enhance_modulePackageInstallationEvents' into d…

ed2a413

…evelopment (#900)

vadi2 added a commit that referenced this pull request Apr 21, 2017

Added internalisation do's and dont's (#927)

f1cff28

* Added internalisation do's and dont's This is based on feedback we have collected at: #900 http://forums.mudlet.org/viewtopic.php?f=7&t=19499 #926

SlySven deleted the Enhance_modulePackageInstallationEvents branch June 22, 2020 18:54

Uh oh!

Conversation

SlySven commented Apr 16, 2017

Uh oh!

SlySven commented Apr 16, 2017

Uh oh!

vadi2 commented Apr 16, 2017

Uh oh!

vadi2 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SlySven commented Apr 16, 2017

Uh oh!

vadi2 commented Apr 17, 2017

Uh oh!

vadi2 commented Apr 17, 2017 via email

Uh oh!

SlySven commented Apr 17, 2017

Uh oh!

vadi2 commented Apr 17, 2017

Uh oh!

Chris7 commented Apr 17, 2017

Uh oh!

SlySven commented Apr 17, 2017

Uh oh!

vadi2 commented Apr 18, 2017

SlySven commented Apr 19, 2017 •

edited

Loading

vadi2 commented Apr 19, 2017 •

edited

Loading