Closed Bug 507834 Opened 16 years ago Closed 16 years ago

Collection descriptions should have character limit, not byte limit

Categories

(addons.mozilla.org Graveyard :: Collections, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: davemgarrett, Assigned: smccammon)

References

Details

(Whiteboard: [patch])

Attachments

(1 file)

Collection descriptions currently have a limit of 200 bytes. This is a problem for locales with multi-byte characters. (split off of bug 507329)
Component: Public Pages → Collections
QA Contact: web-ui → collections
See also bug 498080.
Just for the record: (From bug 507329 comment #9) > If I am not mistaken, it is part of bug 503520 and/or bug 503523
Does the character limit count normal space, full-width space, line break, paragraph break? If so how many characters do it take? For languages which use multi-byte characters, it also breaks down into two major types. Some languages use space to separate characters so character count would be significantly larger if included. Some languages don't use or use few spaces and they will be okay to stay within strict limit we are imposing right now. To be fair character limit shouldn't take any spaces or breaks into account. It all comes down to a matter of preference when we say we must be within 200, 300, or 400 characters. However the stricter the limit, the more likely we set a bad limit on certain user groups and run into problems. After all doesn't it really hurt to relax the limit and make more users happy? This would make our lives easier and better cope with users of different cultures and using different locales. Quite a few related bugs filed would have been gone if you set a more lenient limit in the first place. We'd better plan ahead and make sure our solution can *really* cover all test cases and all users using different locales, rather than having a solution which solve part of the problems only. PS: By the way how can I get rid of "Reproducible: Always" when I'm submitting new bugs/suggestions that don't need this? I'm surprised you can do it when I find no way of removing it. Thanks!
@Morlan: Keep comments about bug 507329 in bug 507329. That's why I split this off. This is a bug tracker, not a forum; this bug here is about this bug, only. To answer your question: "test" is 4 characters in 4 bytes "テスト" is 3 characters in 9 bytes That's a tripling (or more, in other cases) of byte usage. More or less spaces doesn't have nearly as much of an effect. There's no real need to ignore spaces in the count. If you really wanted to get anal, you'd need a separate limit for each locale. Yes, some just use more characters than others. However, this is supposed to just be a short description so I don't think we should care as long as they're treated equally. (In reply to comment #3) > PS: By the way how can I get rid of "Reproducible: Always" when I'm submitting > new bugs/suggestions that don't need this? I'm surprised you can do it when I > find no way of removing it. Thanks! Bugzilla has a permissions system. Users who have higher permissions (i.e. "canconfirm" can confirm bugs and "editbugs" can edit any bugs) get an advanced form for submission and can post whatever they need and post as new instead of unconfirmed. The point is to force regular users to always fill in the blanks to post all the needed info, but let us just post the bare minimum because theoretically we know what we're doing. ;)
(In reply to comment #4) > That's a tripling (or more, in other cases) of byte usage. More or less spaces > doesn't have nearly as much of an effect. There's no real need to ignore spaces > in the count. No real need(!!) How is it not a problem if the language uses space to separate *characters* (Read again: characters!!)? Take a look at this before you say space doesn't have an effort: 이 지면을 통해 다시 한 번 정리 해보 기로 하자. Character with space: 15 Character without space: 22 (+47%) You say 47% less if space is included in the calculation. > I don't think we should care as long as they're treated equally. Only if you assume every language works the same as how English works, then we can blindly assume they're treated equally. Incidentally I had to hand in short reviews or introductions about the books I read when I was at school. About 300-600 characters is required per each assignment. Space carries no meaning and is excluded in the character count. It would have been great if space was counted and teachers are no fools. ;-)
Sorry, I'm not sure how the character count works if it's implemented eventually. Let's ask it beforehand to make sure things will be implemented as it should. Don't forget to count all those punctuations correctly as 1 character: * non-English punctuations too (eg. ?!、,。) * full-width space How do you count line break or paragraph break too? Treat it as 1 character literally, doesn't it?
Priority: -- → P3
Target Milestone: --- → 5.0.9
Differences in spacing could add upwards of 50%, but the bytes vs. character problem is a matter of tripling or quadrupling. It's a much more significant problem. Morlan, this is a simple character count. Yeah, some locales will have an effective smaller limit than English and others will have a larger one. Big deal; it's just a quick description. My point is that we shouldn't get over-obsessive over a dinky little description field. (In reply to comment #5) > > I don't think we should care as long as they're treated equally. > Only if you assume every language works the same as how English works, then we > can blindly assume they're treated equally. I'm saying we should treat them equally, not that they would get exactly equal effect.
Assignee: nobody → smccammon
Well my point is why not go to a better happier path if it isn't a big deal to do it either way? You do realise 50% is not a small loss either - you have to convey the whole message with half of the passage only. Principally it is the characters which adds to the meaning of the message (description). Space doesn't convey any more message or meaning. So it makes sense not to count space. As you see teachers at school follow this approach when they ask you to write a short introduction/review.
Target Milestone: 5.0.9 → 5.1
Attached patch FixSplinter Review
Attachment #396855 - Flags: review?(clouserw)
Whiteboard: [patch]
Attachment #396855 - Flags: review?(clouserw) → review+
Fixed in r50585
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: push-needed
Resolution: --- → FIXED
Verified on https://preview.addons.mozilla.org/en-US/firefox/collection/f978319f-f2c4-3d7b-a3ef-5e05810ce990 . Added 200 Korean chars as a description. Tried to modify it, added one more char, and it smacked me with an error.
Status: RESOLVED → VERIFIED
Not sure if this is related but sometime after successfully submitting both the title and description, I'd see Characters used count being over the limit, 50 and 200, respectively. i.e. 66/50 and 217/200 > My point is that we shouldn't get over-obsessive over a dinky little > description field. Agreed. Please increase limit to: 1. 2x for Collection Name 2. 5x (or remove) for Collection Description Should allow user to decide how much info they wish to post.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: