{"ygPerms":{"resourceCapabilityList":[{"resourceType":"GROUP","capabilities":[{"name":"UPDATE"},{"name":"READ"},{"name":"WELCOME_MSG"},{"name":"PENDING_COUNT"},{"name":"ACTIVITY_LOGS"}]},{"resourceType":"PHOTO","capabilities":[{"name":"READ"},{"name":"READ"},{"name":"UPLOAD"},{"name":"UPDATE"},{"name":"DELETE"},{"name":"COPY"},{"name":"MOVE"},{"name":"APPROVE"},{"name":"UPLOADTEMP"},{"name":"GROUPCOVER"}]},{"resourceType":"FILE","capabilities":[{"name":"READ"},{"name":"CREATE"},{"name":"UPDATE"},{"name":"DELETE"},{"name":"AUTO_SEND"}]},{"resourceType":"MEMBER","capabilities":[{"name":"READ"},{"name":"READ"},{"name":"EDIT_MODERATOR"},{"name":"DELETE"},{"name":"CREATE"},{"name":"UPDATE"},{"name":"BAN"}]},{"resourceType":"LINK","capabilities":[{"name":"READ"},{"name":"CREATE"},{"name":"UPDATE"},{"name":"DELETE"},{"name":"MOVE_LINK"}]},{"resourceType":"CALENDAR","capabilities":[{"name":"READ"}]},{"resourceType":"DATABASE","capabilities":[{"name":"READ_DATA"},{"name":"CREATE"},{"name":"READ"}]},{"resourceType":"POLL","capabilities":[{"name":"READ"},{"name":"VOTE"},{"name":"UPDATE"},{"name":"CREATE"},{"name":"DELETE"},{"name":"CLOSE"}]},{"resourceType":"MESSAGE","capabilities":[{"name":"CREATE"},{"name":"READ"},{"name":"DELETE"}]},{"resourceType":"PENDING_MESSAGE","capabilities":[{"name":"READ"},{"name":"UPDATE"},{"name":"DELETE"}]},{"resourceType":"ATTACHMENTS","capabilities":[{"name":"READ"},{"name":"DELETE"}]},{"resourceType":"PHOTOMATIC_ALBUMS","capabilities":[{"name":"READ"},{"name":"UPLOAD"}]},{"resourceType":"MEMBERSHIP_TYPE","capabilities":[{"name":"READ"},{"name":"CREATE"},{"name":"DELETE"},{"name":"UPDATE"}]},{"resourceType":"POST","capabilities":[{"name":"DELETE"},{"name":"CREATE"},{"name":"UPDATE"},{"name":"READ"}]},{"resourceType":"PIN","capabilities":[{"name":"DELETE"},{"name":"CREATE"},{"name":"UPDATE"},{"name":"READ"}]}],"modStatus":"MODERATOR","subStatus":"NORMAL","groupUrl":"groups.yahoo.com","intlCode":"us"},"comscore":"pageview_candidate","ygData":{"userId":12196177,"authorName":"Marc Prior","from":"Marc Prior &lt;mail@marcprior.de&gt;","profile":"lin4trans","replyTo":"LIST","senderId":"8hYKOU5ndSjMnCHVIxm8_jZrIL7ZUHFfRwtvjginI9FUDwDQkFQ-FKReJaMkg-WRUUnAaztH3nOylgUalr8c_F459DLw","spamInfo":{"isSpam":false,"reason":"12"},"subject":"Re: [OmT] glossary function","postDate":"1264936210","msgId":16624,"canDelete":true,"contentTrasformed":false,"systemMessage":false,"headers":{"messageIdInHeader":"PDRCNjU2NTEyLjkwNzA0MDhAbWFyY3ByaW9yLmRlPg==","inReplyToHeader":"PDRCNjUzNzVFLjEwNzAwMDlAYWJzYW1haWwuY28uemE+","referencesHeader":"PDI0ZWMyMGQ0MTAwMTI4MjMyMngxZmJjOWJhYWc4MmIxMDY5ZDc5MWMxYTkyQG1haWwuZ21haWwuY29tPgkgPEFPRUhLQ0tPSU9HUEdDTkxERUtCQUVJT0dIQUEuZC5icmllbEBmcmVlLmZyPiA8MjRlYzIwZDQxMDAxMjkwNDM5aDMzNTcyYTkwcjQwMDUxNDdjMWNlYmY2ZmJAbWFpbC5nbWFpbC5jb20+IDw0QjYzMDNEOS43MDUwMzA2QG1hcmNwcmlvci5kZT4gPDRCNjUzNzVFLjEwNzAwMDlAYWJzYW1haWwuY28uemE+"},"prevInTopic":16623,"nextInTopic":16625,"prevInTime":16623,"nextInTime":16625,"topicId":16567,"numMessagesInTopic":74,"msgSnippet":"... Certainly. But how far do we go? Should we assume that the most basic user needs to be told not to put carriage returns at the end of every line, because","rawEmail":"Return-Path: &lt;mail@marcprior.de&gt;\r\nX-Sender: mail@marcprior.de\r\nX-Apparently-To: OmegaT@yahoogroups.com\r\nX-Received: (qmail 7342 invoked from network); 31 Jan 2010 11:11:57 -0000\r\nX-Received: from unknown (98.137.34.46)\n  by m1.grp.sp2.yahoo.com with QMQP; 31 Jan 2010 11:11:57 -0000\r\nX-Received: from unknown (HELO mo-p00-ob.rzone.de) (81.169.146.160)\n  by mta3.grp.sp2.yahoo.com with SMTP; 31 Jan 2010 11:11:57 -0000\r\nX-RZG-AUTH: :IW0NeWCleu3NCLZrvwV6ORkX9kpsdepz7ym3QvLwqKG/CxzSJ1M8iF0iLl2q0lE=\r\nX-RZG-CLASS-ID: mo00\r\nX-Received: from [192.168.0.139] (p5086FFCE.dip.t-dialin.net [80.134.255.206])\n\tby post.strato.de (mrclete mo60) (RZmta 22.6)\n\twith ESMTP id x05d9am0VB7dUR for &lt;OmegaT@yahoogroups.com&gt;;\n\tSun, 31 Jan 2010 12:10:10 +0100 (MET)\r\nMessage-ID: &lt;4B656512.9070408@marcprior.de&gt;\r\nDate: Sun, 31 Jan 2010 12:10:10 +0100\r\nUser-Agent: Thunderbird 2.0.0.23 (X11/20090817)\r\nMIME-Version: 1.0\r\nTo: OmegaT@yahoogroups.com\r\nReferences: &lt;24ec20d41001282322x1fbc9baag82b1069d791c1a92@mail.gmail.com&gt;\t &lt;AOEHKCKOIOGPGCNLDEKBAEIOGHAA.d.briel@free.fr&gt; &lt;24ec20d41001290439h33572a90r4005147c1cebf6fb@mail.gmail.com&gt; &lt;4B6303D9.7050306@marcprior.de&gt; &lt;4B65375E.1070009@absamail.co.za&gt;\r\nIn-Reply-To: &lt;4B65375E.1070009@absamail.co.za&gt;\r\nContent-Type: text/plain; charset=UTF-8; format=flowed\r\nContent-Transfer-Encoding: 7bit\r\nX-Originating-IP: 81.169.146.160\r\nX-eGroups-Msg-Info: 1:12:0:0:0\r\nFrom: Marc Prior &lt;mail@marcprior.de&gt;\r\nSubject: Re: [OmT] glossary function\r\nX-Yahoo-Group-Post: member; u=12196177; y=57InPb2odlxLudrqr9BDXNMsWVd6bBrvTOPVBdsN0voSY_L-\r\nX-Yahoo-Profile: lin4trans\r\n\r\nSamuel Murray (Durbanville) wrote:\n &gt;\n &gt; Can we agree that the most basic user will not know how to change the\n &gt; file extension?\n\nCertainly. But how far do we go? Should we assume that the most basic \nuser needs to be told not to put carriage returns at the end of every \nline, because text autowraps? Or not to use upper-case o for zero? :-)\n\nMy position is that we assume that users may not know how to change the \nfile extension, but that we deal with that in the documentation, not by \nadjusting the software design to this very basic level of knowledge.\n\n &gt; Then it makes sense that the most basic functions of\n &gt; OmegaT do not rely on the user having to change the file extension.\n\nIn other words, the design of OmegaT is being geared to the knowledge of \nthe basic user, at the expense of the functionality for users with more \nknowledge (not necessarily &quot;advanced&quot; knowledge, and arguably knowledge \nthat they can reasonably be expected to have). Note: I&#39;m not necessarily \ndisagreeing with you in this particular case, just pointing out that \nthere&#39;s a trade-off. As I&#39;ve already said, I&#39;m in favour of applications \nbeing intuitive where appropriate, but at some point users have to be \nwilling to learn, or functionality is severely constrained.\n\n &gt; There is nothing wrong if advanced functions require advanced skills,\n &gt; but the most basic elements of OmegaT should be accessible for the most\n &gt; basic user.  And IMO creating glossaries should not be an advanced skill.\n\nI agree that creating glossaries should not be an advanced skill, but by \nthe same token, I consider the ability understand (the concept of) file \nextensions and to change them to be a basic computing skill.\n\n &gt; The fact that a TMX file will be saved with a TXT extension in some text\n &gt; editors shouldn&#39;t be something to worry about, because editing a TMX\n &gt; file in a text editor isn&#39;t something that a basic user would ever do,\n &gt; would ever want to do or would ever need to do.  But the way to work\n &gt; with glossaries should be something that any dumb user can figure out,\n &gt; and for this reason non-ordinary file extensions should be avoided.\n\nI do agree with this, but today&#39;s basic user is tomorrow&#39;s slightly more \nadvanced user, so extensions are something that are going to have to be \nlearnt about sooner or later. They are hardly advanced features.\n\n &gt; The problem with this argument is that if a user must first realise that\n &gt; he needs to use a non-system encoding, and that means that he must know\n &gt; what the system encoding is, and indeed what an &quot;encoding&quot; is.\n\nYou are right. Hence the &quot;foolproof&quot; explanation in the user manual as \nfar as creating glossaries is concerned.\n\n &gt; Let me repeat my theory that glossary creation (and glossary sharing\n &gt; between translators) would be a an operation aimed at user with only\n &gt; basic skills (not intermediary or advanced skills).\n\nI understand what you&#39;re saying. I think I would say that although \nOmegaT is generally very easy to use, it isn&#39;t intentionally designed to \nbe easy to use at all costs. In the interests of greater functionality, \nusers are expected to have computing ability beyond a very basic level. \nSorry to repeat myself, but I&#39;m afraid I see file extensions as a very \nbasic concept, not much more advanced than knowing that you don&#39;t end \nlines of text with a carriage return, like on a typewriter. Encodings, I \nadmit, are a more advanced issue although I think that a basic \nunderstanding of what they are also constitues basic computing \nknowledge. (As opposed, for example, to knowing what a BOM is, or the \ndifference between Unicode and UTF-8.)\n\n &gt;&gt; So, as I said before, associating .txt with UTF-8 resolves the \nextension\n &gt;&gt; issue in the particular context of glossaries, but it doesn&#39;t \nresolve it\n &gt;&gt; overall: it just postpones it until the next issue involving plain-text\n &gt;&gt; files arises.\n &gt;\n &gt; I hear what you&#39;re saying, but the issue here is not overall user\n &gt; well-being.  The issue is not even the translation of text files (or\n &gt; just dealing with text files).  The issue is glossaries.  It sounds\n &gt; almost as if you&#39;re suggesting that the reason we should not make\n &gt; glossaries easier is that it will rob users of the opportunity to learn\n &gt; something that will be useful to them in later life. :-)\n\nNo, I&#39;m not suggesting that; even in the OmegaT context, there are \nnumerous instances where it&#39;s necessary to understand and use file \nextensions; and not just in the OmegaT context, but in relation to \ntranslation in general.\n\n &gt; The one change that I can see might be worth considering at the moment\n &gt; &gt; is making the .txt extension acceptable for glossaries and associating\n &gt; &gt; it with the UTF-8 encoding. That would solve the most common problem\n &gt; &gt; users have with glossaries, namely changing the extension manually.\n\n &gt; I agree.  This would probably be the easiest solution that would cover\n &gt; most bases.\n\nIt could be described as a pragmatic solution, yes. The only reason why \nit&#39;s a concession to very basic users is that we didn&#39;t originally \nselect it. But we could just as least have made .txt UTF-8 (in both \nsource files and glossary files).\n\n &gt; I would like to touch on a related issue, namely sharing of glossaries\n &gt; between translators.  A Linux translator can currently share his TMX\n &gt; file with a Windows translator, and it will work, but a Linux translator\n &gt; who shares his &quot;system encoding&quot; glossary file with a Windows translator\n &gt; will soon discover that something has broken.  The whole concept of\n &gt; &quot;system encoding&quot; is based on the assumption that users of a certain\n &gt; system will never share any files with users from other systems... and\n &gt; that is precisely what is *not* happening in the translation world where\n &gt; CAT tools are used and glossaries and TMs are shared between colleagues.\n\nAgain, I agree; that&#39;s why I favour the philosohpy of pushing UTF-8 as \nthe default encoding for everything. (But with options for alternatives; \nfor one reason, some people are absolutely dependent upon UTF-16.)\n\n &gt; Dumb text editors will open a UTF-8 file and save it as something else,\n &gt; but hopefully most such text editors will also fail to display double\n &gt; byte characters correctly.  So why not put a sample.txt file in the\n &gt; /glossary/ folder that contains a sample glossary that is UTF-8 and that\n &gt; contains characters that really need UTF-8 to display correctly?  The\n &gt; sample can be in any two languages -- it is a sample only, after all.\n\nI have considered this before now. The sample doesn&#39;t need to be in any \ntwo languages, either. It could contain the most common source terms \nfrom the most common (among OmegaT users) ten languages or so. Including \nRussian, some accented French, Spanish, German terms etc.\n\nMarc\n\n"}}