{"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":229380146,"authorName":"Jean-Christophe Helary","from":"Jean-Christophe Helary &lt;fusion@mx6.tiki.ne.jp&gt;","profile":"jc_helary","replyTo":"LIST","senderId":"bET8GP9BTECXv0YI-e1OdUHpDFHaBx0_9VSPmPUjNJCahFSAofqwwh6tZU6FJ6rZQG8s-dTBDkibonggMUI9DJlad5SmPgq2MA1Y-YudO-pwC2y6kw","spamInfo":{"isSpam":false,"reason":"0"},"subject":"Re: [OmT] Beginners and the &quot;project&quot; concept... A simplification proposal...","postDate":"1166324784","msgId":7310,"canDelete":true,"contentTrasformed":false,"systemMessage":false,"headers":{"messageIdInHeader":"PEFCOUNGRjM2LTlDQUEtNDRCNC04QUNCLUUwRjcyNTVCMDA0RUBteDYudGlraS5uZS5qcD4=","inReplyToHeader":"PDIwMDYxMjE2MTg0Ny4wNjU0OS5tYWlsQG1hcmNwcmlvci5kZT4=","referencesHeader":"PDg5RUY0OUVCLUU0MjEtNEE0MC1BN0Q3LUE0NTZDMDA4MjY1QkBteDYudGlraS5uZS5qcD4gPHdlYi0yMTg2NDI5MjdAc3BlZWR5LnR1dGJ5LmNvbT4gPEVEODZDRjZELUY4QzQtNEU2Ny05OTM1LUI0REY3NEU5OEU0QUBteDYudGlraS5uZS5qcD4gPDIwMDYxMjE2MTg0Ny4wNjU0OS5tYWlsQG1hcmNwcmlvci5kZT4="},"prevInTopic":7304,"nextInTopic":7311,"prevInTime":7309,"nextInTime":7311,"topicId":7277,"numMessagesInTopic":24,"msgSnippet":"... To put in differently, and so that reflects the RFEs that I linked to as a reply to Dmitri, the current system allows for 2 things only: -create project by","rawEmail":"Return-Path: &lt;fusion@mx6.tiki.ne.jp&gt;\r\nX-Sender: fusion@mx6.tiki.ne.jp\r\nX-Apparently-To: OmegaT@yahoogroups.com\r\nReceived: (qmail 75612 invoked from network); 17 Dec 2006 03:07:02 -0000\r\nReceived: from unknown (66.218.66.218)\n  by m27.grp.scd.yahoo.com with QMQP; 17 Dec 2006 03:07:02 -0000\r\nReceived: from unknown (HELO smtp9.tiki.ne.jp) (218.40.30.106)\n  by mta3.grp.scd.yahoo.com with SMTP; 17 Dec 2006 03:07:02 -0000\r\nReceived: from [192.168.11.3] (pl216.nas933.takamatsu.nttpc.ne.jp [210.136.182.216])\n\t(authenticated bits=0)\n\tby smtp9.tiki.ne.jp (8.13.8/8.13.8) with ESMTP id kBH36P5M081359\n\t(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)\n\tfor &lt;OmegaT@yahoogroups.com&gt;; Sun, 17 Dec 2006 12:06:26 +0900 (JST)\n\t(envelope-from fusion@mx6.tiki.ne.jp)\r\nMime-Version: 1.0 (Apple Message framework v752.3)\r\nIn-Reply-To: &lt;200612161847.06549.mail@marcprior.de&gt;\r\nReferences: &lt;89EF49EB-E421-4A40-A7D7-A456C008265B@mx6.tiki.ne.jp&gt; &lt;web-218642927@speedy.tutby.com&gt; &lt;ED86CF6D-F8C4-4E67-9935-B4DF74E98E4A@mx6.tiki.ne.jp&gt; &lt;200612161847.06549.mail@marcprior.de&gt;\r\nContent-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed\r\nMessage-Id: &lt;AB9CFF36-9CAA-44B4-8ACB-E0F7255B004E@mx6.tiki.ne.jp&gt;\r\nContent-Transfer-Encoding: quoted-printable\r\nDate: Sun, 17 Dec 2006 12:06:24 +0900\r\nTo: OmegaT@yahoogroups.com\r\nX-Mailer: Apple Mail (2.752.3)\r\nX-Originating-IP: 218.40.30.106\r\nX-eGroups-Msg-Info: 1:0:0:0\r\nFrom: Jean-Christophe Helary &lt;fusion@mx6.tiki.ne.jp&gt;\r\nSubject: Re: [OmT] Beginners and the &quot;project&quot; concept... A simplification proposal...\r\nX-Yahoo-Group-Post: member; u=229380146; y=mKGrPyN5mDVJNS9rxielF50_13qILkd9FtegaRIZMmgx96DZeg\r\nX-Yahoo-Profile: jc_helary\r\n\r\n\nOn 17 d=E9c. 06, at 02:45, Marc Prior wrote:\n\n&gt; JC,\n&gt;\n&gt; If I understand yo=\r\nu correctly, you are suggesting moving away from  \n&gt; the concept\n&gt; of a pro=\r\nject as a physical location, towards a more virtual concept  \n&gt; of a\n&gt; proj=\r\nect.\n\nTo put in differently, and so that reflects the RFEs that I linked to=\r\n  \nas a reply to Dmitri, the current system allows for 2 things only:\n\n-cre=\r\nate project by creating all project elements from scratch (root \n+omegat+so=\r\nurce+tm+glossary+target)\n-create project by creating some from scratch and =\r\nassociate already  \nexisting others (root+omegat // source+tm+glossary+targ=\r\net)\n\nIt is not possible to create a project by _only_ associating already  =\r\n\nexisting other elements, unless one fiddles with the project  \nstructure (=\r\nnamely move the /omegat/ folder or its contents around).\n\n&quot;[ 1594899 ] crea=\r\nte new project in existing folder&quot; is intended as an  \nanswer to that.\n\nIt =\r\nsupposes that the translator has carefully created a folder for  \nthe sourc=\r\ne files, a folder for existing TMs, one for glossaries, and  \nthe output fo=\r\nlder, everything within an enclosing folder.\n\nWhich is what an organized tr=\r\nanslator is expected to do.\n\nProblem is, OmegaT does not allow that to happ=\r\nen. Because OmegaT  \nconsiders it is OmegaT&#39;s role to create the enclosing =\r\nfolder, that we  \ncall the root folder.\n\nIn fact, OmegaT&#39;s role should be t=\r\no do exactly 3 things:\n-accept the layout provided by the translator if one=\r\n is provided\n-put /omegat/ in a convenient and logical place\n-create a file=\r\n that links everything as a unit (the project).\n\n&gt; You are suggesting takin=\r\ng this a step further and allowing the  \n&gt; source files to\n&gt; be specified n=\r\not only as a folder, but as an alternative also as a  \n&gt; file. By\n&gt; permitt=\r\ning specification of both multiple and single files, you  \n&gt; further\n&gt; simp=\r\nlify the project creation process if the user wishes to select  \n&gt; only a\n&gt;=\r\n single file. (I think the benefit of simplification here is rather  \n&gt; sma=\r\nll, but\n&gt; let&#39;s forget that for a minute.)\n\nIt is not simplification as in =\r\n&quot;dumbing down&quot; it is simplification as  \nin &quot;generalization&quot;, which is way =\r\nmore powerful than generally  \ndumbing down.\n\nThe &quot;layout&quot; I propose above =\r\nis actually just that: a layout. And the  \nelements can be anything support=\r\ned by OmegaT (files in specific file  \nformats or folders containing such f=\r\niles). The nature of the elements  \ndo not matter, only the layout does.\n\n&gt;=\r\n Ultimately, a project would cease to be a &quot;location&quot; (currently the  \n&gt; &quot;r=\r\noot\n&gt; folder&quot;) and would become a &quot;definition&quot;, i.e. a specification of  \n&gt;=\r\n where the\n&gt; various components are. This is already the case, not only bec=\r\nause  \n&gt; some parts\n&gt; of the project can be located anywhere, but because t=\r\nhe core of an  \n&gt; OmegaT\n&gt; project is in fact the file omegat.project, whic=\r\nh contains this  \n&gt; &quot;definition&quot;.\n\nThis is exactly what I am saying. Except=\r\n for the fact that OmegaT  \nwill accept only one possible layout pattern:\n\n=\r\nTry to create a project by using an existing enclosing (root) folder.  \nOme=\r\ngaT will tell you that you can&#39;t because the name is already  \ntaken. This =\r\nis nonsense. OmegaT should just put the /omegat/ folder  \ninside that enclo=\r\nsing thing and handle the overall layout in its  \nsetting file.\n\n&gt; Arguably=\r\n, a &quot;project&quot; could be made synonymous with this file, and  \n&gt; all other\n&gt; =\r\ncomponents could be located anywhere else; we could abandon the  \n&gt; concept=\r\n of\n&gt; associating a project with a &quot;location&quot; (a folder).\n\nNo we don&#39;t. Bec=\r\nause most translators organize their translations as  \nfolders. We just for=\r\nce OmegaT to accept the translator&#39;s layout,  \nwhich OmegaT won&#39;t let us do=\r\n today. There is no technical need to  \nhave everything enclosed in folders=\r\n, but most translators actually  \nuse folders (in all sorts of different la=\r\nyouts) to organize and  \nprepare their data. And there are no technical rea=\r\nsons that an  \nenclosing folder should not contain only one or 2 source fil=\r\nes _not_  \nin a /source/ folder.\n\n&gt; Please correct me if I haven&#39;t understo=\r\nod you properly.\n\nYou are absolutely correct, and the issues you mention be=\r\nlow are to  \nbe handled, although I think those are not really big issues  =\r\n\n(technically speaking)\n\n&gt; I see two issues with this.\n&gt;\n&gt; One is that alth=\r\nough in theory, any project component could be located\n&gt; anywhere, a projec=\r\nt contains some elements for which there is  \n&gt; absolutely no\n&gt; advantage i=\r\nn locating them anywhere else (e.g. project_save.tmx,\n&gt; project_stats.txt) =\r\nother than with omegat.project. In other words,  \n&gt; the &quot;core&quot;\n&gt; of the pro=\r\nject is likely to remain a number of components, and it  \n&gt; remains\n&gt; conve=\r\nnient to group these in a single location which can be  \n&gt; regarded as &quot;the=\r\n\n&gt; project&quot;, even if other parts of the project are located remotely.\n\nI ad=\r\ndressed that in my very first post. The project data is  \nassociated to the=\r\n source (set) file, and is thus put next to it. The  \nproject data (current=\r\nly the /omegat/ folder + omegat.project) could  \nbe put as one folder inclu=\r\nding omegat.project with a name like  \nfilename.omegat.\n\n&gt; The second issue=\r\n: having the project as a &quot;location&quot; enables the  \n&gt; location to\n&gt; be used =\r\nflexibly for other purposes which are related to the  \n&gt; project in the\n&gt; w=\r\nider, commercial sense even if not specifically related to OmegaT.  \n&gt; I ma=\r\nke\n&gt; considerable use of this aspect by adding a number of other folders  \n=\r\n&gt; under my\n&gt; root folder. These may or may not include:\n&gt;\n&gt; incoming - a fo=\r\nlder for incoming files which are not in the format  \n&gt; used by\n&gt; OmegaT (e=\r\n.g. MS Word files; the file in its original form goes in / \n&gt; ncoming,\n&gt; th=\r\ne .odtfile goes in /source)\n&gt;\n&gt; outgoing - as incoming, but for the final f=\r\nile that is sent to the  \n&gt; customer\n&gt;\n&gt; refs - reference materials, which =\r\nmay be provided by the customer  \n&gt; or obtained\n&gt; from elsewhere, e.g. from=\r\n the Internet\n&gt;\n&gt; count - files used for counting purposes (e.g. if the fil=\r\nes for  \n&gt; translation\n&gt; contain large volumes of numerical data which are =\r\nto be retained in  \n&gt; the file\n&gt; for translation but not counted for invoic=\r\ning purposes)\n&gt;\n&gt; revised - files received back from the customer, containi=\r\nng  \n&gt; corrections\n&gt;\n&gt; etc.\n\nOmegaT as I propose it allows to do that _tota=\r\nlly_. You organize your  \ndata in any kind of layout you want, within an en=\r\nclosing folder if  \nyou want, and you just tell OmegaT that all this is you=\r\nr project.  \nOmegaT will accept _your_ enclosing folder as the &quot;root&quot; folde=\r\nr, will  \ncreate the project data folder within it and you are a happy and =\r\n \norganized OmegaT user, because at last, OmegaT will not refuse to  \naccep=\r\nt _your_ enclosing folder as the root folder.\n\n&gt; I find it very convenient =\r\nto keep all this information together. I  \n&gt; began doing\n&gt; this long before=\r\n I began using TM. The technical structure of an  \n&gt; OmegaT\n&gt; project there=\r\nfore follows what I consider to be good practice from a\n&gt; commercial point =\r\nof view, not vice-versa.\n\nI totally agree with that. I only find that Omega=\r\nT&#39;s idea of what is  \na project is limiting, and the biggest problem is: th=\r\nere is a need  \nfiddle with the project _once_ OmegaT has created it its ow=\r\nn way, so  \nthat it fits _your_ idea of what a project is.\n\n&gt; My orders hav=\r\ne always had a /source\n&gt; and a /target folder, even when the order has only=\r\n comprised a  \n&gt; single file.\n&gt; Each order has always had a separate order =\r\nnumber, even if it only  \n&gt; comprised\n&gt; one file which was one line in leng=\r\nth. This might seem unnecessarily\n&gt; bureaucratic to some people, but I thin=\r\nk a certain amount of  \n&gt; organizational\n&gt; structure is necessary for prope=\r\nr management of data.\n\n100% agree with that.\n\n&gt; Of course, not everyone has=\r\n to do things the way I do. it could  \n&gt; also be\n&gt; possible to create a com=\r\nmercial &quot;framework&quot; project and then  \n&gt; &quot;accommodate&quot;\n&gt; the components of =\r\nthe OmegaT project within it. But ultimately, I  \n&gt; think most\n&gt; people wil=\r\nl not simply want to translate &quot;a file&quot;; they will  \n&gt; frequently find\n&gt; th=\r\nemselves managing &quot;a project&quot; of which the file for translation,  \n&gt; even i=\r\nf it\n&gt; is only a single file, is only a part.\n\nI am not thinking in terms o=\r\nf &quot;files&quot; anymore. What constitute to  \nsources is up to the translator to =\r\ndefine, just as is the way the  \nwhole thing is laid out. So we&#39;d be able t=\r\no create projects the way  \nwe do today, or to have OmegaT accept a layout =\r\nthat we have  \npreviously organized, or to do things that are totally diffe=\r\nrent and  \nyet to conceive.\n\n&gt; The solution to me therefore seems to be to =\r\nkeep the concept of a  \n&gt; &quot;project&quot;\n&gt; associated with components located be=\r\nneath a top-level folder,  \n&gt; which is a way\n&gt; of ensuring that they remain=\r\n together, but beyond that to allow the  \n&gt; user the\n&gt; greatest possible fr=\r\needom in structuring the project, with a view  \n&gt; to enabling\n&gt; them to mak=\r\ning the commercial project structure and the technical,  \n&gt; OmegaT\n&gt; projec=\r\nt structure as compatible as possible with each other.\n\nHere again I agree =\r\nwith you. Maybe my first reformulation was a  \nlittle extreme because it fo=\r\ncused on only one pattern that is not  \npossible today.\n\nI think that today=\r\n, with only a few changes in OmegaT&#39;s understanding  \nof what a project is,=\r\n we would go a long way to make OmegaT way  \neasier to handle complex struc=\r\ntures, which would ease the thing for  \ntotal beginners as well as for powe=\r\nr users like I consider we are.\n\nJC\n"}}