<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments for palaso.org</title>
	<link>http://palaso.org</link>
	<description>Website of the Payap Language Software Development Group</description>
	<pubDate>Sat, 04 Feb 2012 19:20:03 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.3</generator>

	<item>
		<title>Comment on XML indentation in .Net by Tim</title>
		<link>http://palaso.org/archives/143#comment-11</link>
		<dc:creator>Tim</dc:creator>
		<pubDate>Tue, 23 Feb 2010 02:44:29 +0000</pubDate>
		<guid>http://palaso.org/archives/143#comment-11</guid>
		<description>Always the troublemaker... glad you asked of course :-)
It seems that mono behaves identically to .net in this case except for one exception (see addendum above). But an equally large issue that I should have caught before did rear its ugly head and that is the difference between newline characters in Linux and Windows land. I changed liftIO to always output "\r\n" for newlines so all should be well now. Glad we caught that.</description>
		<content:encoded><![CDATA[<p>Always the troublemaker&#8230; glad you asked of course <img src='http://palaso.org/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /><br />
It seems that mono behaves identically to .net in this case except for one exception (see addendum above). But an equally large issue that I should have caught before did rear its ugly head and that is the difference between newline characters in Linux and Windows land. I changed liftIO to always output &#8220;\r\n&#8221; for newlines so all should be well now. Glad we caught that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on XML indentation in .Net by cambell</title>
		<link>http://palaso.org/archives/143#comment-10</link>
		<dc:creator>cambell</dc:creator>
		<pubDate>Mon, 22 Feb 2010 20:21:35 +0000</pubDate>
		<guid>http://palaso.org/archives/143#comment-10</guid>
		<description>Dare I ask about the consistent / equivalent behaviour on Mono?</description>
		<content:encoded><![CDATA[<p>Dare I ask about the consistent / equivalent behaviour on Mono?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on WeSay, Palaso, and Linux by kentling</title>
		<link>http://palaso.org/archives/75#comment-7</link>
		<dc:creator>kentling</dc:creator>
		<pubDate>Mon, 24 Aug 2009 13:20:18 +0000</pubDate>
		<guid>http://palaso.org/archives/75#comment-7</guid>
		<description>Hey, thanks for your reflections.  And thanks for your work in getting your programs working in Linux.  When I consider the immensity of the work to be done on the heretofore undocumented languages of the world, and the number of people who don't have (or the cash to buy) up to date proprietary OS/programs, linux just makes sense.  So thanks; I appreciate your work.</description>
		<content:encoded><![CDATA[<p>Hey, thanks for your reflections.  And thanks for your work in getting your programs working in Linux.  When I consider the immensity of the work to be done on the heretofore undocumented languages of the world, and the number of people who don&#8217;t have (or the cash to buy) up to date proprietary OS/programs, linux just makes sense.  So thanks; I appreciate your work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Using SOLID to convert to one-ps-per-sense format by languist</title>
		<link>http://palaso.org/archives/82#comment-6</link>
		<dc:creator>languist</dc:creator>
		<pubDate>Mon, 06 Jul 2009 14:55:11 +0000</pubDate>
		<guid>http://palaso.org/archives/82#comment-6</guid>
		<description>Hi John,

This latest post of yours (from the 27th) introduces
Thanks for another very useful Quick Fix, though I won't quite be able to use it until it supports the standard hierarchy. Currently it assumes that the user is prepared to convert from standard to alternate, which seems unlikely to me.

I imagine the FLEx importer would be happy with either hierarchy as long as the \ps and \sn fields are paired up nicely together, though I've not tested this thoroughly.

What if instead, this Quick Fix first checked to see whether "MDF Unicode" or "MDF Alternate Unicode" was selected when the file was opened, and then:
- If standard, copy \ps down to just above each \sn.
- If alternate, copy \ps down to just below each \sn.

The current wording, "Push \ps down to subsequent \sn's", is ambiguous and therefore perfect. :)

Personally, I think that the alternative hierarchy is more intuitive and better matches FLEx. But from a theoretical standpoint, some linguists would disallow having a single sense with multiple parts of speech. They'd say that multiple senses must be multiple POS's. Of course, FLEx enforces this one-to-one relationship, but MDF Alternate cannot.

Anyways, kudos again for posting this stuff publicly to make it easier to dialog about it in a way others can benefit from.

-Languist</description>
		<content:encoded><![CDATA[<p>Hi John,</p>
<p>This latest post of yours (from the 27th) introduces<br />
Thanks for another very useful Quick Fix, though I won&#8217;t quite be able to use it until it supports the standard hierarchy. Currently it assumes that the user is prepared to convert from standard to alternate, which seems unlikely to me.</p>
<p>I imagine the FLEx importer would be happy with either hierarchy as long as the \ps and \sn fields are paired up nicely together, though I&#8217;ve not tested this thoroughly.</p>
<p>What if instead, this Quick Fix first checked to see whether &#8220;MDF Unicode&#8221; or &#8220;MDF Alternate Unicode&#8221; was selected when the file was opened, and then:<br />
- If standard, copy \ps down to just above each \sn.<br />
- If alternate, copy \ps down to just below each \sn.</p>
<p>The current wording, &#8220;Push \ps down to subsequent \sn&#8217;s&#8221;, is ambiguous and therefore perfect. <img src='http://palaso.org/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>Personally, I think that the alternative hierarchy is more intuitive and better matches FLEx. But from a theoretical standpoint, some linguists would disallow having a single sense with multiple parts of speech. They&#8217;d say that multiple senses must be multiple POS&#8217;s. Of course, FLEx enforces this one-to-one relationship, but MDF Alternate cannot.</p>
<p>Anyways, kudos again for posting this stuff publicly to make it easier to dialog about it in a way others can benefit from.</p>
<p>-Languist</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on More Quick Fixing For SOLID by languist</title>
		<link>http://palaso.org/archives/70#comment-4</link>
		<dc:creator>languist</dc:creator>
		<pubDate>Mon, 08 Jun 2009 18:52:48 +0000</pubDate>
		<guid>http://palaso.org/archives/70#comment-4</guid>
		<description>I just helped a colleague to do the same thing: move \bw etc up to the top of the record, outside of the senses/subentry sections. It worked like a charm! We also were delighted to apply the handy feature for making implicit \sn fields explicit. I've been wanting that feature for a while. I'm sure there are other bulk edit features that could be useful (move \rf to just above \xv ?), but these two cover a lot of ground.
Suggestions: 
1. expand the second feature to make all implicit fields explicit.
2. Add a fix for making all \sn fields empty except for the ones that should be published (i.e. ones that have sibling \sn fields). Renumber if necessary.

(I'm also submitting these ideas to the developer separately.)</description>
		<content:encoded><![CDATA[<p>I just helped a colleague to do the same thing: move \bw etc up to the top of the record, outside of the senses/subentry sections. It worked like a charm! We also were delighted to apply the handy feature for making implicit \sn fields explicit. I&#8217;ve been wanting that feature for a while. I&#8217;m sure there are other bulk edit features that could be useful (move \rf to just above \xv ?), but these two cover a lot of ground.<br />
Suggestions:<br />
1. expand the second feature to make all implicit fields explicit.<br />
2. Add a fix for making all \sn fields empty except for the ones that should be published (i.e. ones that have sibling \sn fields). Renumber if necessary.</p>
<p>(I&#8217;m also submitting these ideas to the developer separately.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on WeSay: What&#8217;s it all about by chris.hirt</title>
		<link>http://palaso.org/archives/62#comment-3</link>
		<dc:creator>chris.hirt</dc:creator>
		<pubDate>Sun, 29 Mar 2009 23:21:34 +0000</pubDate>
		<guid>http://palaso.org/archives/62#comment-3</guid>
		<description>Great job on the video, Cambell (or whoever put this together).  It's a great summary of how WeSay (and Palaso) is making a big impact in minority language development!</description>
		<content:encoded><![CDATA[<p>Great job on the video, Cambell (or whoever put this together).  It&#8217;s a great summary of how WeSay (and Palaso) is making a big impact in minority language development!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

