Good you asked.
Because right on answering I became aware that my CustomStrings component is currently relying on being the last one in the queue of loaded components. And this of course isn't guaranteed. :(

Yes, long time ago I made it ... and my own knowledge was rather limited those days. I'll release an update soon.

Z Man, thanks for the info on the language files, didnt know that. I was kind of thinking the same thing on this whole UI for mentions thing, its just not going to be performant and seems to be more of a con than a pro.

As for the language file: All seperate language file arrays are getting merged to one large array in the end - so any string definition may be done in any single single file ... it will be recognized.

That's BTW one reason I wrote in my guidelines: derive the start of any key from your component's name. Otherwise there's a chance that things will get overwritten when the merge is complete.

Same is true for component functions. Just 'deleteSomething' would even crash Ossn on enabling if another component is already using 'deleteSomething'. So it's strongly recommended to name a function like 'comcomponentnamedeleteSomething'

My opinion regarding your lib: Useful for just a small bunch of users, but I can't image to keep the complete userbase like that!?

Z Man,

1st, regarding Allon, are you saying I could add those lines to my component and it would do the same thing? If so then v1.9 coming up. I also thought about the Custom Strings component but forgot to reply.

2nd, regarding me, this library actually fires as soon as the @ character is selected and if there is no data in the json object then it aborts thinking it's supposed to do anything with it. That's why the json object has to probably be created at login if I were to do this and I wouldn't want to lose that valuable data and have to do it all over again at some point during the same login so using a window variable would help persist the data.

@Bryce
to answer your question first: No, the complete user base is not part of the session.
What I can think of would be having some kind of ajax state machine with
1. observing the input in general
2. if a '@' gets detected - take extra care and check for the next space, next word and another space: then do the db query and offer a list of names to select from. if a name has been selected, save current end of string position and fall back to 1
3. if not, wait for the next word/space pair and do another query. if max number of word/space pairs has been reached without selection, save current end of string position and fall back to 1

just a first skeleton of an idea in order to keep the selection list as short as possible

Wrong approach, Allon!
You should either ask Bryce or Softlab24 for adding these translations to their components, or better use the "Custom Strings" component and add them there, because otherwise you'll loose it with the next release of the OssnNotifications component.

Here's the code I added to ossn.en.php in the locale folder of the OssnNotifications component.

'ossn:notifications:mention:post:created' => '%s mentioned you in a post.',

'ossn:notifications:mention:comment:created' => '%s mentioned you in a comment.',

Works great!

https://photos.app.goo.gl/saYPMFUR8M9nfafZ7 link to image

One major hurdle for example is that this library like most expects a JSON object of all users to be available at all times or through an API call. Now obviously on a very small user base I could do an "on the fly" query and there would probably be very little lag but doing this on a large db is a bad idea. Im kind of wondering if at login we query the db for users and store the user full name and user name for each user for the session or set an expiration of some kind.

Its actually a pretty slick library and unfortunately we cant support some of the perks of it within OSSN like turning the mention into a hyperlink to the user profile for example. Thoughts?

WIll try it out, thank you.