On Jul 13, 10:54 am, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> Um, you do realize that you don't normally need any kind of
> hyphenation in web applications?
All depends on what you mean by 'web applications'.
This is defiantly a good feature for mobile devices. Also there are
many filters
Am 11.07.2007 um 07:49 schrieb [EMAIL PROTECTED]:
> I welcome any and all help!!! I don't see this as anything crucial or
> time sensitive.
> For my part I want this feature for a project, and at worst can
> include the code as an app there. I just believe it should be part of
> the django
On Jul 10, 11:12 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Don't decide that this hinges on "fully internationalize humanize or it
> shouldn't go there". Incremental changes are good.
agreed.
>
> > There are four reasons why I feel it is better to have this as part of
> > the core:
>
On Tue, 2007-07-10 at 18:26 +, [EMAIL PROTECTED] wrote:
>
> On Jul 9, 10:48 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
> wrote:
> > Maybe an addition to django.contrib.humanize?
>
> If we decide to only support English, then I am fine with including
> this as part of
On Jul 9, 10:48 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Maybe an addition to django.contrib.humanize?
If we decide to only support English, then I am fine with including
this as part of django.contrib.humanize.
If we decide to properly internationalize humanize, then I am fine
with
Since the algorithm is identical to the one used by TeX, the hyphenation
data can be taken from there as well. I used a TeX distribution to get
the latest patterns for English to include in the module. I installed
MiKTeX, and dug around in the tex/generic/hyphen directory to find
them.
Todd, good to meet a fellow nerd: I also have the five-volume hardcover
set. My code is implemented from appendix H of volume 1 (or is it volume
A?).
--Ned.
Todd O'Bryan wrote:
> On Tue, 2007-07-10 at 02:54 +, [EMAIL PROTECTED] wrote:
>
>> On further reflection, there is a huge
On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Ticket with initial patch made: http://code.djangoproject.com/ticket/4821
>
> It still needs documentation and unit testing (and
> internationalization) but it is a start. Will try to get to the doc
> and test this weekend.
+1 from me.
Ticket with initial patch made: http://code.djangoproject.com/ticket/4821
It still needs documentation and unit testing (and
internationalization) but it is a start. Will try to get to the doc
and test this weekend.
-Doug
On Jul 9, 10:30 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
>
On Jul 9, 11:59 pm, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> I'm not sure what you mean by this; "public domain" means anyone can
> do pretty much whatever they want with it, without restriction.
I mean he wanted his code in the public domain with working data so
that restricted him to data
On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The code Ned put up contains data from the public domain and
> was most likely restricted due to that.
I'm not sure what you mean by this; "public domain" means anyone can
do pretty much whatever they want with it, without restriction.
On Jul 9, 11:07 pm, "Todd O'Bryan" <[EMAIL PROTECTED]> wrote:
> I seem to remember that Knuth did a pretty amazing job with hyphenation
> in TeX, most of it was algorithmic, and there were hyphenation engines
> for at least a few languages.
Ned's implementation is taken directly from this, and
On Tue, 2007-07-10 at 02:54 +, [EMAIL PROTECTED] wrote:
> On further reflection, there is a huge internationalization issue
> here. The hyphenation rules and data driven exceptions are English
> specific. Some will work (minimally) for other languages, but are not
> good enough. Proper
On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Ned just posted the code for the tabblo hyphenate filter in the public
> domain.
[snip]
> Thoughts?
Maybe an addition to django.contrib.humanize?
Jacob
--~--~-~--~~~---~--~~
You received this message
Ned just posted the code for the tabblo hyphenate filter in the public
domain. This should be added as a builtin django filter with proper
attribution. I don't think wordwrap should use it by default, and
optional arguments don't work. I was thinking of just calling it
'hyphenate' or
15 matches
Mail list logo