mightylemon / mightylemon

What does this look like? settings.py munging? or is there an interface for this?

Perhaps something like the architecture from django-plugins(on my github) would be good.

Let's say that at this time I'm not sure to be able to implement this sort of idea, so take it just as a mind dump, also I haven't looked at django-plugins project by now (edit: after reading the docs in django-plugins it seems quite similar to what I wrote in this comment :) .

I think that maybe a normal django app could be extended to implement some sort of Mightylemon-plugin interface that permits the use of the app in a django project in the usual way (hook up in urls.py) and alternatively the reuse of the same codebase as a mightylemon plugin. The administration panel can have a "plugins" page that autodiscovers apps that implement that interface from the python path (too heavy?) and let you activate/deactivate the plugin;
Also installing from a trusted repo via web interface is quite cool but file system permission can bring huge pain.

I haven't looked into how to handle the syncdb step in this case (but probably also other mightylemon-specific plugins would require that step)

I also think that some "optional features" already built-in (like elsewhere or gravatar) should be pluginified (but included in the standard distribution of mightylemon).

The great downside I see to this plugins all the way down idea is that trying to generalize too much could imply a shift of focus from the real problem (building a great blog app)

thanks for your work, I hope to contribute in the future :)

It seems to me that this could possibly be tied to django sites framework?

I'm already on this one.

I contacted a dude about helping design a generic looking template but haven't heard much back for a week or so. I'll keep working on this. Feel free to remove your templates from the main repo though.

When I wrote my original blog engine I adapted a wordpress theme(a good one!) to be the default. Perhaps we could do something similar if we find a good one with a sufficiently permissible license.

Spent some time this evening messing about with html goodness. Don't know if its worth a damn, but here's what came of it. http://bit.ly/AOS7c

Oooh. I like that design a lot. I'd use something like that for my blog.

I've pushed what I've done so far to a new_theme branch of ML.

this can bring some sort of database backed settings (maybe djblets.siteconfig from reviewboard can be useful)

I need to move this branch over to the main account.

Realistically, let's think about how this can play out.

A) User installed via pip

pip --upgrade mightylemon

B) User installed via archive

cd /path/to/mightylemon
wget http://mightylemon.com/ml.zip
unzip ml.zip

C) User installed via VCS

cd /path/to/mightylemon
(vcs update command)

--

What these don't take into account: schema changes, local changes to the project (templates, etc), etc. I think we need to set expectations on what an update really entails. Is it clicking a button and its updated? Is it running a script? If we know what our ideal solution is, we can perhaps work towards it a bit better.

I'm Italian but I haven't any experience in translating software, but I can try to do something (translating seems quite boring in relation to programming!!)
I heard about something like django-rosetta... any advice (tools, practices...) on the matter is welcome. Just don't take this words as a promise at the moment :D

OK I've done some initial translation one for every single app that needed it using django-rosetta.

Now some question comes to my mind:
What should I write in line 2 and 3 (copyright owner and license [BSD?]) of headers for translation files?
At the same link, on line 7 I set "Project-Id-Version" as "projectname-appname" (in django it's simply "django"). What do you think?

I've put my changes in http://github.com/scotu/mightylemon/tree/locale-it but I haven't requested a pull via github because I don't know if you have some policy (ok it's not code but maybe you want to review it or something or maybe you prefer patches...) and who to ping for this (the mightylemon user?)

Please note that commit scotu/mightylemon@4428c32 also adds a __unicode__ method to the AuthorProfile model... sorry about not mentioning it in the commit message...

Talking about themes/template translation (that's where the interface really gets translated) I find it quite messy: the problem is that I need to create the translation catalogs in the main project directory; doing so the translations end up being mixed in one file: all the themes/templates you have and also the apps contained into the project dir go in a single file using djamgo-admin.py makemessages -l=it

any advice?

I have a twitter pluggable (multi-account) i'm wrapping up which sends statuses when the admin updates a post. I could extend this a little to go bidirectionally if anyone is interested.

That sounds pretty cool! We don't really have a great way to do plugins yet, but feel free to explore this a bit. I'm mostly interested in displaying my (one) most recent status somewhere on my blog... but I'm sure everyone is interested in something different.

this should be fixed in scotu/mightylemon@37a087f

Other (little) work has been done in my locale-it branch on translatable strings apart from italian translations if you are interested

Thanks for the answer. I've got one more question to you. How do you deal with locale settings? After I set LANGUAGE_CODE='pl' I have to do some hacks to have archive working. Here is what happens:

1. template filter some_date|date:"b" returns for example "czerw" as month name (it is "jun" in Polish) and it is no longer compatibile with urls resolver expecting (?P[a-z]{3})

2. Post model's get_absolute_url is not affected by locale and it always returns 'jun'. The method get_absolute_url uses strftime and not django.utils.format. The latter returns 'czerw'. Strange but this is how it works for me.

3. I can't just add month_format to generic view because the format is also hardcoded in get_absolute_url, so I also have to modify this method.

I wonder what is your solution for the above issues.

I've noticed that too, but I haven't dugg into the problem right now... I'm glad you've done so :) thanks

The best long term solution I see is avoid using the three-letters formatting for the month but go with the number. Doing so the url does not need to be translated and we can have one url for one resource instead of lots of urls for one resource (web crawlers...)

I'm looking forward other proposals...

Yup. This is what I did. I replaced %b with %m (number of month) in blog.models.Post's get_absulute_url and changed blog.models.urls adding a month_format:'%m' to date_based_dict as well as modfied regexes to expect a number: (?P\d{2}).

fixed that too :D scotu/mightylemon@37a087f

same issue for me, this fix makes it better. thanks