I'd like to ask at prepan, but they seem to be rather elite, only permitting one to login via twitter or github, neither of which I have. And I am not about to start up with twitter, so I may have to forego the prepan experience.
You may not have grasped the utility of the module I'm proposing. It is not an encoding issue. It has nothing, actually, to do with encoding. It does operate within the auspices of Unicode, being specifically designed for UTF-8. But it does not convert anything, it simply identifies what is already there. Basically, it adds tokens to the regexp engine so that additional characters can be recognized within the Thai/Lao language. For example, in English, you can identify a space in a number of ways:
If you didn't have those options, you would be unable to find a space for your regexp to work with. English regexes can distinguish between alphabetical (word) characters (\w) and numerical digits (\d), etc. Until now, there is no way to do this in Thai or Lao. My modules are providing these tools for Thai and Lao so that the language can be more readily parsed via Regexp. What I'm really doing with this module is adding character classes to the standard Unicode properties, as can be found listed on pp. 167 - 175 in Programming Perl, 3rd Edition.
I certainly appreciate your input, but I don't see much of a direct relationship between my module and the Encode:: line of tools. With all due respect, this topic has frustrated me. I had expected a little more unanimity among the various responses, but I have discovered that everyone has a different perspective. At this point, it appears that no matter what I might choose, it has a good chance of displeasing the majority. That's not a fun position to see oneself in.
| [reply] |
... or github, neither of which I have.
Are you using Git or another VCS? Because if not, it's a really good idea, and Git / GitHub makes collaboration much easier.
I had expected a little more unanimity among the various responses, but I have discovered that everyone has a different perspective. At this point, it appears that no matter what I might choose, it has a good chance of displeasing the majority.
It's a community, not a centrally governed system with strict rules :-) Releasing useful, tested code publicly already gives you a lot of points, so it's unlikely to upset anyone unless you do so without thought in a top-level namespace; and it seems like you're putting a whole lot of thought into it. If you want to play it safe, start off in an X::Y::Z namespace; I think Thoughtstream gave some good advice in that respect above.
| [reply] |
good chance of displeasing the majority
Well, there hopefully is a difference between not pleasing them and explicitly displeasing.
That said, what about Regexp::UTF8::Thai (Update: or Regexp::Thai::UTF8)?
| [reply]
[d/l]
[select] |
Regexp is definitely not the place to post character sets, definitely ... except that it is :) um, I changed my mind
well actually UTF8 definitely belongs nowhere , characters ranges aren't UTF8, this module doesn't deal with UTF8 ... sure the OP wrote
$char = "..."; # some UTF8 string
but he meant some unicode string
So after some more research Regexp::Cherokee - Regular Expressions Support for Cherokee Script.
Regexp::Ethiopic - Regular Expressions Support for Ethiopic Script.
Regexp::CharClasses - Provide character classes
Regexp::EN::NumVerbage - Regex pattern to match English number verbage
+ in text
Regexp::CharClasses - Provide character classes
I propose the one new namespace to rule them all Regexp::CharProps - User Defined Character Properties like \p{InKona}
So for the OP Regexp::CharProps::Thai - \p(InThaiDigit} and other thai language character properties definitions | [reply]
[d/l]
[select] |