--- Log opened Fri Nov 11 00:00:30 2005
00:09 >> SignOff: adamhill_work (Remote closed the connection) [#punt-dev]
00:40 >> SignOff: _dreaminofjeanni (Read error: 104 (Connection reset by peer)) [#punt-dev]
00:40 >> #punt-dev JOIN _dreaminofjeanni (i=adamhill@ppp-70-242-26-241.dsl.hstntx.swbell.net)
00:42 >> _dreaminofjeanni is now known as adamhill
00:45 >> dpatton is now known as dpatton_away
02:04 >> SignOff: adamhill (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference") [#punt-dev]
02:12 >> #punt-dev JOIN adamhill (i=adamhill@ppp-70-242-26-241.dsl.hstntx.swbell.net)
06:45 >> #punt-dev JOIN [1]adamhill (i=adamhill@ppp-70-242-26-241.dsl.hstntx.swbell.net)
06:55 >> #punt-dev JOIN mazop (n=mazop@212.183.13.231)
06:58 >> SignOff: adamhill (Read error: 110 (Connection timed out)) [#punt-dev]
06:58 >> [1]adamhill is now known as adamhill
07:24 >> dpatton_away is now known as dpatton
07:42 >> dpatton is now known as dpatton_away
07:47 >> SignOff: mazop (Read error: 104 (Connection reset by peer)) [#punt-dev]
08:02 >> #punt-dev JOIN mazop (n=mazop@212.183.13.231)
08:38 >> SignOff: adamhill (Read error: 104 (Connection reset by peer)) [#punt-dev]
08:38 >> #punt-dev JOIN adamhill (i=adamhill@ppp-70-242-26-241.dsl.hstntx.swbell.net)
11:22 >> #punt-dev PART mazop (n=mazop@212.183.13.231) ()
12:25 >> SignOff: adamhill (Read error: 104 (Connection reset by peer)) [#punt-dev]
12:25 >> #punt-dev JOIN adamhill (i=adamhill@ppp-70-242-26-241.dsl.hstntx.swbell.net)
14:30 >> #punt-dev JOIN adamhill_work (n=86a3fd7e@70.84.174.194)
14:48 >> SignOff: adamhill_work (Remote closed the connection) [#punt-dev]
14:58 >> #punt-dev JOIN adamhill_work (n=86a3fd7f@70.84.174.194)
15:23 >> dpatton_away is now known as dpatton
16:05 >> #punt-dev JOIN [1]adamhill (i=adamhill@ppp-70-242-26-241.dsl.hstntx.swbell.net)
16:17 >> SignOff: adamhill (Read error: 110 (Connection timed out)) [#punt-dev]
16:17 >> [1]adamhill is now known as adamhill
17:58 < dpatton> In 1 hour there will be a discussion in #punt-dev regarding some issues with using GNU gettext in Punt.
17:58 < dpatton> This will include adding support for providing translations for Plugins and Addons.
17:58 < dpatton> Everyone is welcome to attend :-)
18:00 >> dpatton is now known as dpatton_away
18:17 >> #punt-dev JOIN Bull_[UK] (i=MeGA@worldwind/user/bull)
18:31 >> dpatton_away is now known as dpatton
18:52 >> #punt-dev JOIN mazop (n=mazop@dsl-85-98.utaonline.at)
18:57 < dpatton> Hi everyone - it's time for the "gettext in Punt" meeting :-)
18:57 < dpatton> I'll start by pasting in some text that gives a bit of background...
18:57 < mazop> he
18:57 < mazop> hi dave...
18:58 < mashi> hi!
18:58 < mazop> hey mashi...coding and checkins ike in olddays ;)
18:58 < dpatton> well, at least 3 people at the "meeting" ;-)
18:58 < Bull_[UK]> any one bring pizza?
18:58 < dpatton> anyone else want to say hello before we start?
18:59 < dpatton> hi Bull_[UK] !
18:59 < Bull_[UK]> hi
18:59 < mazop> mashi: btw....i am not sure about, but is punt defaults set to 'convert to dds' ?
18:59 < Bull_[UK]> ;)
18:59 < mazop> if... maybe think about that ;)
18:59 < dpatton> mazop: shhh - that's not on the meeting agenda! ;-)
18:59 < mazop> hey bull :)
18:59 < Bull_[UK]> hi mazop
19:00 < ShockFire> hehe
19:00 * mazop shouts his mouth ......
19:00 < dpatton> hi Tim
19:00 < adamhill_work> hi
19:00 >> #punt-dev JOIN hobu_work (n=chatzill@hobu.cssm.iastate.edu)
19:00 < dpatton> hi Adam
19:00 < ShockFire> hey dave
19:00 < dpatton> hi "hobu" ;-)
19:00 < mazop> hi @ everyone !
19:00 < ShockFire> I think I'll translate Punt to dutch this weekend, or otherwise somewhere next week
19:00 * mazop otherwis we need hoursjust for greetings ;)
19:01 < Bull_[UK]> lol more of you turned up than fr ww meetings
19:01 < dpatton> ShockFire: ok, cool - the info you need is on the For Translators webpage: http://punt.sourceforge.net/4translators.html
19:01 < ShockFire> yep, I know
19:01 * mazop didnt know about punt-meeting.......hmmm...
19:02 < ShockFire> I don't think I've ever missed a WW/Punt meeting :)
19:02 < dpatton> OK, lets start - I'll paste in a bit of background info....
19:02 < dpatton> Some notes on how GNU gettext is used in Punt.
19:02 < dpatton> gettext 0.14.5 manual: http://punt.sourceforge.net/gettext/gettext_toc.html
19:02 < Bull_[UK]> nope but you never speak
19:02 < dpatton> There are two parts to gettext - the runtime, and the tools.
19:02 < dpatton> We use the tools to process POT, PO, and DLL files.
19:02 < dpatton> The gettext runtime take a string, and returns a "translated string".
19:02 < dpatton> The gettext runtine is used by incorporating 'gettext for C#' into the Punt project,
19:02 < dpatton> so we have the opportunity to alter/enhance the gettext code.
19:02 < dpatton> In 'traditional'(i.e. C programs on Unix) usage of gettext, the name and location
19:02 < dpatton> of the file that gettext uses to obtain the translated string is determined by
19:02 < dpatton> both the values of environment variables, and by specifying a "domain".
19:02 < dpatton> The 'gettext for C#' implementation uses the thread's CurrentUICulture, the
19:02 < dpatton> 'basename' used when an object of type GNU.Gettext.GettextResourceManager
19:03 < dpatton> is created, and some hardcoding of the path, relative to the Punt executable.
19:03 < dpatton> The first time that a string is passed to gettext, it looks for the resources
19:03 < dpatton> file(a DLL) for the CurrentUICulture. If that's not found, it will look for
19:03 < dpatton> the resources file for the parent of the CurrentUICulture. If that isn't found,
19:03 < dpatton> then the original string is returned(therefore English is always supported,
19:03 < dpatton> even without any language DLL files).  For example, if CurrentUICulture is
19:03 < dpatton> de-AT (German(Austria)) ad that resource file isn't found, then it will
19:03 < dpatton> look for the de (German) resource file.
19:03 < dpatton> The contents of resource files are loaded into hashtables, so the penalty
19:03 < dpatton> of looking for the files is confined to the initial lookups.
19:03 < dpatton> OK, that's the "background"
19:03 < ShockFire> bull: hehe, yeah
19:03 < ShockFire> for those who didn't pay attention I will quote dave: "stuff."
19:04 < Bull_[UK]> hehe
19:04 < dpatton> The first "problem" is 'short or ambiguous strings'
19:05 < dpatton> for example, in Punt, on the View menu, you can select Camera, and then select from Normal or "Free Look" camera
19:05 < dpatton> "Normal" is marked as a translatable string in the Punt code.
19:06 < dpatton> If "Normal" was to also be used elsewhere, then there would only be one entry for "Normal" in the PO file, which might cause problems for translators, if the two usages had different meanings and therefore had different translations
19:07 < dpatton> The gettext manual suggests using longer strings in the sourcecode: http://punt.sourceforge.net/gettext/gettext_10.html#SEC170
19:08 < dpatton> basically, "View|Camera|Normal", and having a function to strip out the "prefix"
19:08 < dpatton> My question - anyone see any issues with adopting that approach? Can anyone see where the pipe symbol(|) would be used in 'translatable text'?
19:09 < ShockFire> does that string show up as something to translate, or just the word "Normal"?
19:10 < adamhill_work> there is no way to annotate the PO file ("this 'Normal' means...") to provide context?
19:10 < dpatton> If we used "View|Camera|Normal" in the Punt source, it would show up for the translator as "View|Camera|Normal", however, they could just translate "Normal"
19:11 < dpatton> yes, comments can be placed in the Punt source, which then will show up in the PO file, and on the poEdit comments portion of the screen
19:12 < ShockFire> I think it would work, though I consider it a hack
19:12 < dpatton> however, that doesn't solve the issue of there only being a single instance of "Normal", even if there are multiple instances within the Punt source
19:13 < dpatton> the "marked text"(i.e. a string like "Normal") in the Punt source becomes the key in the gettext hashtable, so two instances of the same string, which may need to have two different translations, need to use two different "marked text strings"
19:14 < mashi> do we have a case where the translation of one string becomes 2 different strings in the translated string?
19:14 < mashi> (needs to)
19:15 < ShockFire> you mean as in:
19:15 < dpatton> sure - the string "M" - in English, it stands for both Months and Minutes, but won't necessarily work in other languages
19:15 < ShockFire> 'kom' kan be both 'bowl' and 'come'
19:16 < dpatton> the most obvious problem comes from 'short strings' such as things like menu items, button text, etc.
19:16 >> #punt-dev JOIN T_Servo_Work (n=c6d0fb17@70.84.174.194)
19:17 < dpatton> so, any more on this topic before moving on?
19:17 < dpatton> ok :-)
19:18 < dpatton> The bigger question is - how to implement support for internationalization of Plugins, Addons, and XML files
19:20 < dpatton> For Punt, we use a single "domain"(gettext terminology" - "Punt" - so that we end up with all translatable Punt strings in a single PO file, and therefore one DLL file(Punt.resources.dll) per language
19:21 >> #punt-dev JOIN Llynix (n=Miranda@worldwind/developer/llynix)
19:21 < dpatton> For Plugins, we would have to allow plugins to be able to specify the domain to be used(e.g. the plugin name), and they would have to follow the Punt/gettext method of dealing with the multiple language DLLs
19:22 < dpatton> The only way I can see that working is for each plugin to have it's own domain, in order to avoid conflicts
19:23 < dpatton> to me, that means enforcing that language DLLs for plugins have to be in subdirectories of the Plugin's directory
19:23 < dpatton> Anyone see any problems with that approach?
19:23 < Llynix> I thought dll's had to be in the same directory?
19:24 * Llynix wanted all the ww dll's in a system directory
19:24 < dpatton> Llynix: we are talking about "language DLLs" - they can be loaded from anywhere
19:26 < dpatton> I guess everyone agrees(or is sleeping ;-)
19:26 < mashi> yes, dlls can be loaded from anywhere
19:27 * mazop wakes up - and agrees ;)
19:27 < mashi> my input is try and keep the number of directories to a minimum?   Have you considered putting the language code in the filename?
19:27 < dpatton> Punt allows the user to configure the location of the Plugins directory, and the expectation is that each Plugin has it's own directory
19:28 < dpatton> where there could be problems is with plugins that aren't installed that way - i.e. installed directly into the Plugins directory
19:29 < T_Servo_Work> they only need their own directoy if it was more than 1 file
19:29 * T_Servo_Work doesn;t see a need for a folder for 1 file
19:30 < mashi> earthquake.dll, earthquake-en-AU.dll, earthquake-de.dll ?
19:30 < dpatton> I'm reluctant to change how gettext is setup - to have language DLLs located in directories named according the the language(Culture) - because gettext is a well-established way of doing globalization
19:31 < dpatton> T_Servo_Work: if a Plugin was translated into 5 languages, that would be 5 additional files
19:31 < T_Servo_Work> Ok, fine.. but you have to get the person to want to do that
19:32 < mashi> it seems kind of compllicated to have to create a directory for each of the translations containing only 1 file each?
19:33 < T_Servo_Work> Um...
19:33 < adamhill_work> hmmmm has any other project had to deal with this?
19:33 < dpatton> that's how it's done for hundreds of programs that use gettext
19:33 < T_Servo_Work> from the little I have cought.. your making this more clumbersom and confusing than it was before
19:34 < dpatton> there is another possibility, which is to use the directory structure Punt uses - problem there is that could lead to "collisions", if two plugins specified the same "domain"
19:34 < dpatton> T_Servo_Work: "before"?
19:35 < T_Servo_Work> ok, currently in WW
19:35 < adamhill_work> are there any plugins with the same names?
19:35 < mazop> ...not as i know...
19:35 < adamhill_work> the closest we have come to in WW land is 'OnEarth' and 'OneEarth'
19:36 < adamhill_work> what about another 'declaration' in the comments up top and make the PluginEngine declare the domain some how </handwave>
19:37 < adamhill_work> *comments in the Plugin
19:37 < adamhill_work> same for the add-on loader
19:37 < dpatton> so for the domain, do we use the name of the plugin file - myplugin.cs = domain of "myplugin" - or allow the plugin author to specify the domain in her code?
19:38 < adamhill_work> or make them decalre it and make sure they agree
19:39 < dpatton> hmmm - I guess the plugin loaded in effect enforces unique plugin names, if you include the directory name(s), so the domain could be enfored to be 'path to plugin' + plugin.cs filename
19:39 < dpatton> plugin loader in effect...
19:41 < dpatton> ...\Plugins\Fred\\Plugin1\myplugin.cs = domain of "Fred-Plugin1-myplugin"?
19:42 < dpatton> then the German language file for that plugin is: ...\Punt Program Directory\languages\de\Fred-Plugin1-myplugin.resources.dll
19:43 < dpatton> Two problems I see with that approach:
19:44 < dpatton> 1) it means that some of the files associated with a plugin are no longer in the same location as "the rest of that plugin's files"
19:45 < dpatton> 2) Users may run into problems, if they have access to install Plugins, but don't have write access to the location of the Punt executable
19:45 < dpatton> To extend the discussion, we also need an approach that will work for Addons and XML files
19:46 < dpatton> you could certainly end up with naming collisions between Plugins and Addons and XML(e.g. layer) files
19:46 < mashi> for source code snippets it would perhaps also be nice if the string table could be a part of the source file?
19:46 >> SignOff: T_Servo_Work ("heading home") [#punt-dev]
19:47 < dpatton> mashi: I disagree - that breaks the whole notion of using gettext, and readily available tools for translators such as poEdit
19:48 * dpatton unless I didn't understand what you were saying ;-)
19:50 < mashi> you could still use poedit, and then merge it all into a single file for distribution. 1 file = easy distribution
19:51 < mashi> plugins will often have < 10 strings, but I understand what you are saying ;)
19:51 < dpatton> so, to sum up so far - Punt enforces the domain name based on the path+name of the Plugin/Addon/XML file, but not everyone agrees with where the language DLLs should be located?
19:51 < dpatton> not sure what you mean by "could still use poedit, and then merge it all into a single file"?
19:53 < dpatton> do you mean having multiple translations in one file? So a plugin with 10 translatable strings and two translations would have 20 translated strings in one file?
19:54 < mashi> yes, here's the contents of your australian translation for punt:
19:54 < mashi> Hashtable hashtable1 = base.Table;
19:54 < mashi> hashtable1.Add("Welcome", "G'day Mate");
19:54 < mashi> this could be added to the source, I know it violates some principles ;)
19:56 < dpatton> I don't see what advantage that provides - it certainly won't work with gettext, and therefore with Punt's use of gettext
19:56 < mashi> sorry.. go back to the agenda
19:57 < dpatton> to me, all that sounds like is a plugin author providing their own method of supporting multiple languages in their plugin(for which they would have to provide their own interface to the user to make their selection)
19:58 < mashi> dpatton> The 'gettext for C#' implementation uses the thread's CurrentUICulture,
19:59 < dpatton> What it does raise is a good point - there needs to be a way for plugin authors to know what language a user has selected in Punt, in case they DO want to implement their own mechanism of multi-language support
19:59 < dpatton> I think we can rely on CurrentUICulture, and perhaps raising an event if the language is changed
20:00 >> SignOff: adamhill_work (Remote closed the connection) [#punt-dev]
20:00 < dpatton> ANyway, one more "agenda item"(I'm sure most people have 'left' already)
20:00 < dpatton> see- there goes Adam :-)
20:01 < dpatton> How do we deal with being able to translate the information that is in things like property attributes?
20:02 < dpatton> For example:
20:02 < dpatton> 		[Browsable(true),Category("General")]
20:02 < dpatton> 		[Description("The number of times the program has been started since installation.")]
20:02 < dpatton> 		public int ApplicationStartCount
20:03 < dpatton> we want to be able to allow translators to provide translations for "General" and "The number of times the program has been started since installation."
20:05 < mashi> I think it might be possible to tweak ReadableNamesProxyDescriptor.cs http://10.0.0.254/cgi-bin/viewcvs.cgi/Punt/PluginSDK/Configuration/Browsing/ReadableNamesProxyDescriptor.cs?rev=1.2&view=markup
20:05 < mashi> I'm more worried about the xml files?
20:06 < dpatton> I'm not sure, but xgettext(used to extract strings from the source) allows for specification for multiple "keywords" that indicate text to be extracted, so it may be possible to use "[Description" as a keyword, but that doesn't help because there's nothing in the code to cause Punt to try and look for the extract string(or it's translation)
20:08 < dpatton> I don't see the XML files being as much of a problem.
20:10 < dpatton> Each XML element that is in an XML, for which we would want to enable translations, somehow gets assigned as "the text property" of some object. We use I18N._() for those assignments, so that the gettext runtime will do a lookup to find the translated value(if any) of the string being assigned.
20:11 < dpatton> The difference is, instead of using xgettext to extract the strings from C# sourcecode, we will need to have a way to extract the translatable strings from the XML files.
20:12 < mashi> do you see 1 language.dll per translation and xml?
20:13 < mashi> or do they share punt's dlls?
20:14 < dpatton> we could do that with an XSLT transform - maybe a "Punt utility program" that takes 'a bunch of XML files', builds the transform output in memory, then writes it out to a file 'properly marked for extraction by xgettext', so that xgettext can produce a proper POT file?
20:16 < dpatton> well, by "XML files" we mean things like \Config\Earth\@Images.xml etc?
20:16 < mashi> yes
20:17 < dpatton> I think the only way to "cleanly" avoid namespace collisions between various XML files, Addons, and Plugins is to have the language DLLs be located in "\languages" subdirectories, and within \languages nave one directory for each Culture
20:19 < dpatton> so the Norwegian translation for strings in \Config\Earth\@Images.xml would be in  \Config\Earth\languages\de\@Images.xml.resources.dll
20:20 < mashi> I still prefer \Config\Earth\@Images.de.dll  (doesn't cause a collision either)
20:20 < dpatton> that approach will certainly work, but, there may be lots of small files, with few strings in each file
20:22 < mashi> on the plus side it will be easier to handle?
20:23 < dpatton> instead, we could have  \Config\Earth\languages\de\xml.resources.dll where something like "<Name>Blue Marble Base (2048x1024)</Name>" in @Images.xml gets extracted as "@Images.xml|Blue Marble Base (2048x1024)", and then all XML strings go into one xml.pot file
20:24 * dpatton this is why the first issue I brought up was the idea of using the pipe character in conjunction with short strings - I knew it might be applicable "later on" ;-)
20:24 < dpatton> we could take a similar approach for Plugins and Addons
20:26 < mashi> please let's not have many languages\de directories? ;)
20:26 < dpatton> The downside is that if things are aggregated together, then every time there's a new Plugin/Addon/XML file, someone has to extract it's strings, and merge them into the existing POT file
20:27 < mashi> I guess we'll need a tool for that?
20:28 < dpatton> I think we will have to allow people to configure the location of the \languages directories, because sysadmins may not want them located where Punt.exe is located
20:28 < mashi> rather than piping all strings, maybe we could just do it on those strings that actually need it?
20:29 < dpatton> problem is, for XML/Addons/Plugins, you have no way to know in advance "those strings that actually need it" - someone can create a new XML/Addon/Plugin tomorrow that uses an existing string, in a different contect that requires a different translation
20:30 < dpatton> there are only two ways around that - separate files for each XML/Addon/Plugin, or fully qualified names in common files
20:32 < dpatton> In the Punt sourcecode, I'm only suggesting piping some of the strings, because in that case there is a 'controlled universe' of potential strings
20:33 < dpatton> mashi: don't think anyone else is "here", so I'll ask you ;-)
20:34 < mashi> ok.. how about starting the string with a special character?  (to avoid having to search all strings for containing "|" on lookup?
20:35 < dpatton> you want to see something like ...\de\Punt.resources.dll ...\de\Addons.resources.dll ...\de\Plugins.resources.dll ...\de\XML.resources.dll ?
20:35 < Llynix> I'm here
20:35 < Llynix> I'm just not paying attention :)
20:35 < dpatton> so there is only one directory that contains German language DLLs?
20:36 < mashi> very minor issue, just want the file system to be as clean as possible  (by removing "\" from paths when there's only going to be 1 file in each directory)
20:36 < Llynix> just an idea to throw out..  but a lot of language problems could be handled via the installer..  ie replace default xml files with a localized version, install dlls etc.
20:37 < dpatton> "starting the string with a special character" - why? if we use | in the strings, you only need to search backward from the end of the string to the first | character to find the 'true' string to be returned
20:38 < mashi> yes, but you have to do this for every lookup of every string in the program.. ;)
20:39 < mashi> = it will be costly to lookup strings inside the render loop
20:39 < dpatton> Llynix: that's not practical, because in Punt people can select the language, and then text from XML files should also change - picture Punt on a PC in a European school, with students using different languages
20:40 < dpatton> mashi: yes, I'm also wondering about the "cost" of using |
20:40 < Llynix> hrmm
20:40 * Llynix doesn't see why it doesn't apply with multiple languages
20:41 < Llynix> what your planning on doing.. is providing an 'override' for the xml names?
20:42 < dpatton> one option is to do this - use | in the marked strings, but instruct translators to only translate "the last part", and don't do any "lookup to see if there is a | character"
20:42 < mashi> and if there is no translation?
20:42 < mashi> available
20:43 < dpatton> the downside to that is that it means we have to have an English DLL file, because if a translation isn't found, the "original string" is returned, which without the English DLL, would contain the | character(s)
20:44 < dpatton> we could have conditional code to only do the | lookup if there is no translation found, however, to cover all the bases
20:45 < dpatton> Llynix: we aren't talking about 'overriding' the names of the XML files, but rather some of the text within them, such as layer names
20:45 < Llynix> that's what I was refering to
20:46 * Llynix would rather see localized xml sets
20:46 < dpatton> basically looking at being able to have "every peice of text" that a user sees be in the language of their choice(assuming the translations have been done)
20:46 < Llynix> especially when you talk about something like localizing placenames
20:47 < dpatton> so you mean something like de.@Images.xml for the "German @Images.xml file"?
20:48 * Llynix nods
20:50 < dpatton> it's a possible approach - it does mean that translators end up dealing with editing, in this case, XML files, rather than using established tools such as poEdit, and it means that the advantages of using the gettext tools for management of things like mergind existing translations with new text requireing translation are lost
20:50 < dpatton> merging existing
20:53 < dpatton> The simpler we can keep things for translators(all strings in one file, using existing cross-platform tools, etc), the better - more change of then being willing to do a translation, and then to be willing to keep doing updates, as things change over time
20:54 < mashi> keep all strings in 1 file (including plugins+addons...)?
20:55 < dpatton> I'm thinking I'll look into using 4 files per language: Punt.resources.dll, Plugins.resources.dll, Addons.resources.dll, and XML.resources.dll
20:56 < Llynix> for translators I'd just send them a text file full of english strings and have them send you one back in their language :)
20:56 < dpatton> translators using poEdit can setup "Translation Memory databases", which makes translating the "same string" more than once easier
20:57 < dpatton> Llynix: not going to do that - it's way too much work - there's a reason people spent years developing/refining 'standard tools' such as gettext ;-)
20:58 * Llynix shrugs
20:58 < Llynix> people know how to handle text
20:59 < dpatton> trust me - I've been the one doing the "management" of dealing with the Punt language files so far, and for only two languages, and you really do need a set of tools to deal with managing things like mergeing new text with existing translations, etc :-)
21:01 < mashi> screenshot: http://www.poedit.org/screenshots/snapshot1.png
21:02 < dpatton> Anyway, thanks for everyone's input - talking about the possibilities has helped to clarify a few things.
21:02 < dpatton> Next step is to look at doing some implementations - it's more important to get something working, even if it's not "perfect", than having nothing at all :-)
21:03 < mashi> llynix has a point about the installer. if you need french and german on the same PC, installing the app twice to different locations would also work
21:03 < Llynix> or you could just select both french and german in the installer
21:04 < mashi> but of course the instant selection feature is more sexy
21:04 < Llynix> there is no reason for say me.. to install any other language other then english
21:04 < Llynix> I mean.. I know a little esperanto.. but I don't see the value of it
21:04 < mashi> ahhh.. of course
21:06 < mashi> so in the installer you could pick which languages to install and in the program you could choose among those?
21:06 < dpatton> Llynix: by default Punt always support English - once things are further along, we'll have basically three options for people - no language files(i.e. only English), a 'pack' of language files, or just a single language file
21:07 < dpatton> that applies to both the installer, and for downloads
21:08 < dpatton> mashi: installing Punt twice to different locations, of itself, won't work, because they would share the same Punt.xml settings file
21:09 < mashi> not if the users were different?
21:09 < dpatton> you may as well just install it once, setup two different directories, and have two different shortcuts to start Punt
21:09 < dpatton> true - I thought you menat for the same user
21:11 >> #punt-dev JOIN adamhill_work (n=86a3fd7e@70.84.174.194)
21:11 < mashi> best thing to do is probably for you to go ahead and implement it.. afterwards I'm sure we'll have a lot more opinions about it ;)
21:11 * Bull_[UK] drags himself away from the excitement and watch smallville ;)
21:12 < dpatton> ok, now that Bull is watching TV, and Adam is back, we can declare the meeting officially over ;-)
21:15 < mashi> for plugins namespace + plugin classname could also be used as the "unique key"
21:15 < adamhill_work> sorry I had to install 2005
21:20 < dpatton> For most people, 2005 installed itself, at midnight on January 1 ;-)
21:20 < adamhill_work> mashi do you actually need proj.4 as a .NET assembly for something or were you just asking? I compiled it, but havent had a chance to see what kind of DLL came out (in vs2005)
21:21 < dpatton> mashi: you mean use the classname to avoid conflicts within the plugin's own namespace? we haven't run into that within Punt
21:29 < mashi> adamhill_work: don't exactly need it, I was just wishing.. let me know if you manage to make an assembly out of it?
21:30 < mashi> yes, namespace + classname will always be unique (for loaded classes/plugins) or the compiler will complain?
21:36 < adamhill_work> mashi: that is correct AFAIK
21:37 < adamhill_work> and I will let you know
21:37 < dpatton> adamhill_work: what is it you are doing with proj4 - using VS2005 to compile the C code to a Windows DLL?
21:39 < adamhill_work> correct, suppoosedly in VC2005 you can just compile a C++ DLL project and have a managed DLL come out the other end, in 2003 there was some combination of flags you have to throw
21:41 < adamhill_work> vs2005 had some complaints about "str<something> being unsafe please consider using <some function>" so I dont know if it produced a mananged or native DLL (i fell asleep before checking)
21:46 < dpatton> ok, just wondering - at some point I'd like to be able to compile GNU gettext tools to have a copy that runs on Windows - I may have to do that via MingGW + Mono however
21:49 * mazop tired -> bed -> dreams ;)
21:54 >> #punt-dev PART mazop (n=mazop@dsl-85-98.utaonline.at) ()
22:00 >> #punt-dev PART Bull_[UK] (i=MeGA@worldwind/user/bull) ()
22:04 < adamhill_work> i compiled proj.4 with gcc in Cygwin on Windows
23:04 >> SignOff: adamhill_work (Remote closed the connection) [#punt-dev]
--- Log closed Sat Nov 12 00:00:55 2005