Archives/2007-01-02
From LangCom
![]() |
This page is no longer maintained and may be outdated: moved to m:Special projects subcommittees/Languages/Archives/2007-01-02. |
Archived discussion |
This is an email discussion about policy held between 02 January and 18 February 2007. The GerardM-Pathoschild draft was implemented. |
1. |
GerardM <this user has not agreed to public archival.> |
2. |
Karen Broome <this user has not agreed to public archival.> |
3. |
Gerard Meijssen <this user has not agreed to public archival.> |
4. |
Jesse Martin Dear Gerard, I think it's a good step in the right direction, but the final policy should list definitive steps and requirements with as little discussion and circumlocution as possible. For example, it should not discuss the problems and history of voting for most of a paragraph; it should simply say that languages are assessed on their own merits, and votes are not counted. It also leaves many important questions unanswered. For example, who decides requests? What are the distinct steps users should follow, and what information should they provide? What are the technical steps involved in actually adding the request to the page (creating the subpage, adding the information in the templates, et cetera)? One major requirement I see for a policy is simple formatting and organization. A policy should be divided into distinct sections for easy reference and reading. If I'm wondering what the prerequisites are, for example, I simply read <http://meta.wikimedia.org/wiki/WM:LPP#Prerequisites>; I should not have to read through the entire policy to find what I'm looking for scattered throughout the writing, then re-read it again whenever I want to remember or refer to a particular piece of information. I think the easiest and quickest solution would be to add all the information in your proposal to the currently implemented policy and tweak the rest as desired. Yours sincerely, <this text is quoted from a user who has not agreed to public archival.> |
5. |
Jesse Martin Hello, I discussed with GerardM on IRC about our respective drafts last week. As I see them, my original draft was primarily a process and GerardM's draft was primarily a set of criteria and considerations, so they are complementary when merged. We agreed that I would draft a new proposal merging the two with changes according to the discussion. The new draft can be found at <http://langcom.wikimedia.org/wiki/Language_proposal_policy/GerardM-Pathoschild>. All drafts are listed at <http://langcom.wikimedia.org/wiki/Language_proposal_policy>. Yours cordially, |
6. |
Gerard Meijssen <this user has not agreed to public archival.> |
7. |
Karen Broome <this user has not agreed to public archival.> |
8. |
Jesse Martin Hello Karen, I've corrected the problems you've found, except the portion about proposing new codes. The codes are more GerardM's or your specialty; feel free to correct the policy as desired. Yours cordially, |
9. |
Jesse Martin Hello subcommittee, If there are no other comments in a few days, I'll implement the policy and prepare requests that are ready for the subcommittee. In case anyone lost the links, you can read the latest policy at <http://langcom.wikimedia.org/wiki/Language_proposal_policy/GerardM-Pathoschild>. All drafts are listed at <http://langcom.wikimedia.org/wiki/Language_proposal_policy>. Yours cordially, |
10. |
Gerard Meijssen <this user has not agreed to public archival.> |
11. |
Jesse Martin Hello, Alright then; we should forward the proposal to the board and committee if there are no further comment in a few days. I think a simple message like the following would suffice; any thoughts? "The language subcommittee has reached consensus on the draft policy for proposing new language editions of existing projects at <http://langcom.wikimedia.org/wiki/Language_proposal_policy/GerardM-Pathoschild>. We would like some input regarding the policy from the Special Projects Committee and Board of Trustees. If there are no further changes needed or opposition forthcoming, we will implement it in about a week and begin processing the backlog of requests." Yours cordially, |
12. |
Karen Broome <this user has not agreed to public archival.> |
13. |
Karen Broome <this user has not agreed to public archival.> |
14. |
GerardM <this user has not agreed to public archival.> |
15. |
Karen Broome <this user has not agreed to public archival.> |
16. |
Jesse Martin Hello, Sorry for the long delay in response; I was offline for a week. I know relatively little about ISO 639 codes, my specialty lying more towards streamlined process and policy. I'll adjust the policy to suit whatever decision we reach on codes. The Ethnologue Google search we're recommending is awkward; I'm putting together a comprehensive searchable database of ISO 639 codes for this purpose at <http://www.pathos.ca/tools/ISO639DB>. The database currently includes all ISO 639 1-3 codes, and allows users to search by code or language name. Both English and native names are included in the ISO 639 1-2 matches. Of particular use to our purposes is the ability to restrict search results to any combination of fields, code lists, scopes, and types. This is done through the URL, so a link from the policy would already include all the configuration needed to suit, with the user needing only fill in the search box. If we only want codes from ISO 639-1, for example, we'd link to <http://www.pathos.ca/tools/ISO639DB/index.php?iso639_1=true>. Yours cordially, |
17. |
Gerard Meijssen <this user has not agreed to public archival.> |
18. |
Karen Broome <this user has not agreed to public archival.> |
19. |
Jesse Martin Hello, The codes are used for both validation and identification (in URLs and encoding), but the latter is the more important use. Validation is better achieved through information on sites like Wikipedia and Ethnologue. Karen suggests we use RFC 4646, which matches web document language encoding. I have no opposition to that solution. A code list is available through the Language Subtag Registry<http://www.iana.org/assignments/language-subtag-registry>, and could easily be converted into a searchable database if none exists. Whichever standard we use, I'd like to settles this as soon as possible. We stopped processing requests *three months* ago during the reform, and the process has been on hold since. We should hold a meeting as soon as feasible to discuss the remaining issues. Yours cordially, |
20. |
Jesse Martin Hello, If there is no objection by tomorrow, the policy will recommend RFC 4646 with a fallback to ISO 639-3 (which will eventually be integrated into or compatible with RFC 4646, if I understand correctly). I'll give it a couple of days after that for any discussion on the new draft, and then I'll forward it to the special projects committee for feedback. Yours cordially, |
21. |
Gerard Meijssen <this user has not agreed to public archival.> |
22. |
Jesse Martin Hello, That seems to fit with what I suggested. We'd thus accept a code from either RFC 4646 or ISO 649-3. There are some projects that would benefit from a dialect-specific codes; there are even some existing projects separated on the basis of *simplicity of use*, with no significant linguistic difference. That doesn't necessarily mean we'd accept en-US, but it would be available if we do. If this is not what you envision, what do you want in terms of codes? Should we accept only a particular standard, or one with the other as fallback, both equally, or something else entirely? I'd like to get these issues resolved as soon as possible and get the process back on its feet. Yours cordially, Jesse Martin <this text is quoted from a user who has not agreed to public archival.> |
23. |
GerardM <this user has not agreed to public archival.> |
24. |
Jesse Martin Hello, If I understand correctly, the IANA lists integrate or will integrate these codes; the requesting users need only concern themselves with the ISO 639 codes. Is this correct? Yours cordially, |
25. |
Jesse Martin Hello, I've adjusted the policy based on recent discussion (see <http://langcom.wikimedia.org/w/index.php?title=Language_proposal_policy/GerardM-Pathoschild&diff=124>). Feel free to make any changes you think would be beneficial. If there are no further comments, I'll forward it to the special projects committee. Note that it will still be possible to make changes to the policy later, so it's not necessary to make it absolutely perfect before we begin to use it. Yours cordially, |