<div class="gmail_quote">2009/9/4 Ceki Gulcu <span dir="ltr"><<a href="mailto:ceki@qos.ch">ceki@qos.ch</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span style="color: rgb(102, 102, 102);"><snipped></span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
If I understand you correctly, the spreadsheet would be used to</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
transform a resource bundle from one encoding to another? It would</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
read in one encoding and write in another. Right?</span><br></blockquote></div><br>No, sorry I didn't explain it more clearly. The spreadsheet would be 'the' source file for all the languages in a bundle. Each language has its own column. The first column lists the keys so that reading across each row, the key is followed by one or more language strings, each in a different language and each being a translation of the others.<br>
<br>Using the spreadsheet, the hypothetical compiler would simply extract the keys and in turn each language column would produce a corresponding properties file. The properties file encoding can be whatever you want (so choose UTF-8 or stick with nasty old 'native2ascii' ASCII files). Or output to XML.<br>
<br>IIUC, spreadsheets allow the complexities of character encoding to be hidden from the user.<br><br>In my limited experience of working with translation services, this is an approach they like.<br><br clear="all">Rick<br>
-- <br>Big Bee Consultants Limited : Registered in England & Wales No. 6397941<br>Registered Office: 71 The Hundred, Romsey, Hampshire, SO51 8BZ<br>