Menu
▾
▴
Re: [Openrocket-devel] New wiki + translation
|
From: Boris du R. <bor...@ne...> - 2013-02-17 09:02:39
|
Sampo Sounds good to me. I will give it a go with the French translations. Then could make the sourceforge ones read only (if possible) so that we do not keep several repository updated. Regards Boris -----Original Message----- ------------------------------ Message: 5 Date: Sat, 16 Feb 2013 14:05:54 +0200 From: Sampo Niskanen <sam...@ik...> Subject: [Openrocket-devel] New wiki + translation To: OpenRocket development mailing list <ope...@li...> Message-ID: <CAD7zinaAkXt2MpCALqQpy=j1M...@ma...> Content-Type: text/plain; charset=ISO-8859-1 Hi, I discovered recently the Translation extension for MediaWiki, and I think that is definitely the way to go for wiki translation. It allows paragraph-by-paragraph translation of wiki pages, change tracking, and informing users when some part of the page is out-of-date or when new content has been added to it. It's much better than trying to keep separate versions of the pages in sync with each other. Since the SourceForge wiki is disappearing at some point, I set up a new wiki for the time being at http://sampo.kapsi.fi/wiki/ . It can be moved to a better location in the future. I transferred all the English pages to the new wiki. The translated pages need to be moved by hand once the pages have been set up for translation. As an example, I have copy-pasted the FAQ page translation for French: http://sampo.kapsi.fi/wiki/index.php?title=FAQ I added a page for instructions to translators at http://sampo.kapsi.fi/wiki/index.php?title=Instructions_for_translators Please test the system and let me know what you think. Also do you have opinions on whether anonymous editing and/or translating of the wiki should be allowed, or whether we require people to create an account first? The same system can later be used for the software translation as well, as it supports property file import and export. There's already a community-driven translation site at https://translatewiki.net/ and I've discussed a bit on what would be needed to get OpenRocket there. They're quite picky on the quality, and several things in the current translations need to be fixed first (especially the use of patchwork messages): http://www.mediawiki.org/wiki/I18n#Internationalization_hints Cheers, Sampo N. ------------------------------ Message: 6 Date: Sun, 17 Feb 2013 10:29:48 +0200 From: Sampo Niskanen <sam...@ik...> Subject: [Openrocket-devel] Future ideas on textures To: OpenRocket development mailing list <ope...@li...> Message-ID: <CAD7zinbh31Cc-5bRhorwRy6iRO9pu04WoRq=HmV...@ma...> Content-Type: text/plain; charset=ISO-8859-1 Hi, Some ideas on the future textures (not wanting to push new features before the next release)... I now have a good balsa texture finally done. I used an image from the net (it turned out that it was quite picky on the original image) and it took a while to get permission to use it. The problem is that as a JPG the texture is 50kB, while as a transparent overlayable PNG it's 730kB. The latter is quite heavy to be included within ORK files. I've been wondering on how to get the clean overlayable textures in a smaller size. The essential part for creating the overlayable texture is Gimp's Color to Alpha plugin. The only thing you need to do is to figure out the suitable background color to make transparent, and everything else works like magic. I suggest that after the next release, we implement that algorithm into OR, so that when a decal image defines it, it's taken into use. The functionality might be visible in the UI, or only applied when a texture image "requests" it. (Another thing that we eventually may want to control is the decal image opacity.) I've been thinking that the meta-data of textures could be included in the comment of the images. For example the balsa JPG would contain "Alpha: #e3ceb9" in the comment section, indicating that the texture should be first filtered via color-to-alpha with that parameter. Similarly there could be a "Background: #xxxxxx" parameter to suggest setting the base color when loading the texture. The problem is that currently the JOGL code loads the textures from the InputStream directly. What other alternatives exist, so that we could implement the filter before loading it as a texture? Or should we implement the filter itself within JOGL as well? If JOGL could load textures from, say, a BufferedImage then we could have a method DecalImage.getImage() which would return the processed image. Does this have some downsides? The color-to-alpha algorithm is quite simple. I wrote a piece on it at http://stackoverflow.com/a/14915403/412896 Cheers, Sampo N. ------------------------------ ---------------------------------------------------------------------------- -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ------------------------------ _______________________________________________ Openrocket-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openrocket-devel End of Openrocket-devel Digest, Vol 28, Issue 4 *********************************************** |