Skip to main content

Seeing something I haven't seen before, building something that never existed before.

Collecting new skills and experiences like precious shinies.

Technology Strategist & @elgg expert, occasional @withknown contributor, Hacker, Wanderer.

Have laptop, will travel.

www.marcus-povey.co.uk

www.linkedin.com/in/mapkyca

www.twitter.com/mapkyca/

www.flickr.com/photos/mapkyca/

github.com/mapkyca

plus.google.com/+MarcusPovey

www.instagram.com/marcuspovey/

www.patreon.com/mapkyca

angel.co/mapkyca

Big tune, big remix. Blistering guitar. https://www.youtube.com/watch?v=MkgR0SxmMKo

Oh wow. Video even has Blade and Buffy in it. https://www.youtube.com/watch?v=60ruvzfXQoE

Replied to a post on github.com :

I'm not sure I fully understand, but I don't think there's a need to completely throw everything out.

The wrappers go around english strings, because using token strings is horrible in terms of legibility and converting existing strings, and also goes against gettext's standard.

The interface of the wrapper's is as it is because of maintaining compatibility with the old translation method, but if we adopt gettext fully (recommended) the interface could obviously be changed.

There are a few places where the wrappers are used around segments of strings side by side in template pages, which preserves english order (which I think is your point..?). This isn't a fault of the translation mechanism, rather it's a fault of my lack of time, and can easily be changed. It doesn't need a rewrite of the translation engine, it just needs those templates to be modified and the strings updated.

Also, you can totally pass variables to translation engine. I may not have done this in some places, because time :)

Replied to a post on github.com :

Latest code has some more logging, might want to give it a try...

@gomezr Yes and no. Known doesn't internally make much use of caching, but this tool is a utility that could be used in high load environments if you modify your code to make use of it.

Replied to a post on github.com :

Interesting... so you're saying that https://yoursite.com/profile/skddc works but https://yoursite.com doesn't?

Replied to a post on github.com :

If you have a single user install you _can_ use the domain, but you have to explicitly set "single user" mode. This is because that mode puts the user header on the top of the front page, which has all the rel=me links that IndieAuth uses...

Replied to a post on github.com :

I wonder if it makes a difference between single user install / multi user installs.. e.g. it'll be hard to auth a single user on a mulituser install if you enter https://example.com/ instead of https://example.com/profile/me

Replied to a post on github.com :

Hmm... bridgy seems to not like private accounts. I'll see if I can create a new instagram and try again...

Replied to a post on github.com :

Hmm... do we have a record of what's sent to known / getting from known? (I've not got a public instagram, so not tried to replicate)