Re: [native-lang] Status update season!
On Thu, Dec 28, 2006 at 01:16:37AM +0100, Lars Aronsson wrote: Christian Lohmaier wrote: Swedish dictionary (which is from 2003, but almost unchanged since 1997) has 24,489 basic forms and expands to 118,270 variations. This is clearly inferior. So here you see another problem. If a language has lots of variations of a single word, how can you judge that not 12000 of the expanded words are based on useless words (not in widespread use, hiding typos,...) or the other way round: You cannot tell that the important ones are present. What I can tell you is that it is impossible to cover the important words in Swedish if your expanded list only contains 118,270 words unless they were hand-picked, and I know they are not. You seem to be of the opinion that this task is impossible, but it is not. The topic was: Measuring the quality/comparing the quality of dictionaries. Having a tag x% completed or something. My point is: You cannot judge it by the number of words alone (apart from telling that a dictionary is really bad). But unfortunately the topic seems to drift away becasue of misunderstandings and/or misinterpretations :-( ciao Christian -- NP: Pantera - Walk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[native-lang] Re: [website-dev] Re: [native-lang] Main Page - maybe translate it?
Hi *, On Sun, Dec 17, 2006 at 10:38:18AM +0100, Johan Beckers wrote: Clytie Siddall schreef: On 17/12/2006, at 1:43 AM, Konrad Stobiecki wrote: [...] I tried to imagine that I am an entrepreneur who does not know English. I enter www.openoffice.org and see Native Language leading to native projects. But if I do not know English, I leave the web page convinced that I am not able to find the language version of OpenOffice.org that suits me. Well, theres still the image of the worldmap inside that button, so even when you don't know what native language means, you could guess from the image. If you mean that http://projects.openoffice.org/native-lang.html itself needs a redesign, then I can tell you that the project pages are already worked on. If you have ideas on how to improve the page to make it more obvious for the visitor, then poste your ideas to dev@website.openoffice.org Sorry for me dropping in on this, but would it not be an idea if we could check the visitors browser and/or system settings, and depending on this redirect the visitor to I don't like detecting of browser langauge or language by IP or something for the content of a webpage. It might work well for mirror-selection (select a mirror geographically near you), but doesn't work very well for website content. the appropriate NL project. Every NL project could place a link to: OpenOffice.org International, or OpenOffice.org Worldwide. The big problem is that by far not every nl-project provides the info the english pages have. You can always visit your NL-project directly using your language-code.openoffice.org - a scheme very widespread across all possible websites. So I'd rather not have automatic selection. The job of the native-language projects furthermore not not to translate everything that is in english, but to create a community in the respective language. There are lot's of common points of course.. ciao Christian -- NP: Metallica - Until It Sleeps - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Help with making torrents needed
Hi Hristo, On Thu, Dec 14, 2006 at 08:27:19AM +0200, Hristo Hristov wrote: Can somebody help me with instructions how to create torrents file of OOo. If the file is hosted on the main mirror network, a torrent will be autogenerated. I'm making a torrent tracker for NL-B and I cannot figure how to create the If it is a OOo download, I'd rather not use/setup a different tracker, but add it to the existing tracker-network. torrent file to upload it on the tracker to test. If you have a torrent already, you're apparently not seeking for help creating one. Please explain again what you really need help with. ciao Christian -- NP: Silverchair - Satin Sheets - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Help with making torrents needed
Hi Hristo, *, On Thu, Dec 14, 2006 at 05:28:37PM +0200, Hristo Simenov Hristov wrote: On 14.12.2006 15:52, Christian Lohmaier wrote: On Thu, Dec 14, 2006 at 08:27:19AM +0200, Hristo Hristov wrote: If the file is hosted on the main mirror network, a torrent will be autogenerated. [...] If you have a torrent already, you're apparently not seeking for help creating one. Please explain again what you really need help with. I want to spread OOo - Bulgarian with torrents. Where to check is there any torrents file for full and language packs in Bulgarian? Well, if you mean to distribute QA'd builds, then just ask to have them distributed on the main mirror-networt and the torrents will be autogenerated and available from http://distribution.openoffice.org/p2p/index.html To have them on the main-mirror network, file an issue with * where to get the builds * md5sum for the builds If you have other stuff in mind that are not distributed using the regular mirros, then instead of a tracker, you would need a seed that uploads the files to the seeds (Hosting the torrent itself on the OOo trackers is no problem) I suggest to use rtorrent, since that needs very few resources, is very configurable, provides the possibility to watch a directory for new/deleted torrents, has a good command-line-user-interface. http://libtorrent.rakshasa.no/ ciao Christian -- NP: The White Stripes - Blue Orchid - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[native-lang] Re: [dev] Re: [users] Re: [discuss] RE: [ooo-announce] OpenOffice.org 2.1 Is Here
On Wed, Dec 13, 2006 at 06:08:46PM +0800, [EMAIL PROTECTED] wrote: Mathias Bauer wrote: [..] Besides that - a hint for all interested readers (as this is a multi post): Niklas Nebel has answered the question on the discuss mailing list. Please follow up there for any further discussions. how to access Niklas Nebel answer on pivot table? Use the archives... http://www.mail-archive.com/discuss@openoffice.org/msg12595.html http://www.openoffice.org/servlets/ReadMsg?list=discussmsgNo=58982 ciao Christian -- NP: Silverchair - Satin Sheets - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] public key for ssh2
On Sat, Dec 02, 2006 at 12:46:36PM -0800, TESFAMICAEL ADHANOM wrote: I submitted an isue for a public key to tunnel to open office around two weeks ago, http://www.openoffice.org/issues/show_bug.cgi?id=71842 . I haven't got a response yet , and am just wondering if submitted the issue right. No http://www.openoffice.org/scdocs/ddSSHGuide#step4 ciao Christian -- NP: Jimi Hendrix - Little Wing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] postcards around the world
Hi Takashi, *, On Tue, Jan 10, 2006 at 10:11:37PM +0900, Takashi Nakamoto wrote: I will publish a RFE issue for supporting functions of Hagaki (postcards in Japan), but I want to know circumstances of postcards around the world in advance. I don't know how postcards are used in each country. About 10 billion postcards are sent a year in Japan. Are more postcards sent in your country? Puh, don't know.. Most postcards are sent from outside germany (from holidays) I guess, others are sent to take part in lotteries/riddles.. Japanese mainly use them for New Year's Greeting. 3 billion are used for this purpose. For what do you send postcards in your country? See above (although I'm not sure, personally I don't send to much postcards apart from holidays since all my relatives live nearby). And I'm not sure about whether more greeting-postcards or more letters with greeting-cards are sent.. The size of Official Postcard in Japan is 100*148mm. Almost the same here.. 105 × 148 (DIN A6) - but postcards can have almost any size, as long as they fit into a standard mail-slot / letter-box Standard size can range from width:140-235 mm height: 90-125 mm (the factor width/height must be = 1,41) Zip codes in Japan are composed by 3 digits, a hyphen and 4 digits. Is it different from yours? Yes. 5 Digits, without hyphen. (but with city), e.g. 12345 City (For american zip-codes, see issue http://www.openoffice.org/issues/show_bug.cgi?id=5948 they can be 5 digits or 5 digits, hyphen, 4digits. In your country, OOo is not required to implement supporting functions to write postcards, is it? Yes. No software must support creation of postcards in germany. Most of the time postcards are written by hand anyway. People won't complain if the software cannot deal with postcards. I've written an article to let you know how postcards works in my country. It is attached in the end of this mail. Please have a look. Very interesting, thank you :-) - Postcards surely aren't used as much in germany as they are used in japan. The only numbers I found regarding postcards is that during peak-times (holiday season) up to 500.000 postcards (coming from foreign countries) per day are delivered. That is about 18.000.000 during from June to August. I have no idea how many postcards are sent from within germany. Other numbers I found: 21.000.000.000 deliveries in section letters per year that includes promotional stuff (advertisments) (9.000.000.000) and press (magazines,..) (2.200.000.000) So when in japan more than 10.500.000 postcards are sent, this is more than the total of both letters and postcards sent in germany. (And I think far more letters than postcards are sent in germany) (note all numers have the zeros added, although the sources speak e.g. of 21 Milliarden - but because of the confustion that may arise because of billions not meaning the same everywhere) [...] * Requirement for OOo - supporting Hagaki dimensions [x] although only by entering the values directy. - Hagaki wizard (auto formatting and printing plural address in turn) [x] Basically a mail-merge, isn't it? - not sure what is involved in auto formatting (maybe a template will do?) - complementing address function for Base This is more tricky. [...] ciao Christian -- NP: nichts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Opinions about OOo future
Hi *, On Sun, Jan 08, 2006 at 12:11:39PM +0100, Bernhard Dippold wrote: [...] A foundation that could collect money and spend it especially for OOo development would probably be helpful. It could coordinate sponsorship for coding competitions or sponsor developers working on the OOo code. [To clarify my point a bit: Not necessarily sponsor itself (if it has the financial backround, then of course it can act as a sponsor itself) - but handle the necessary administrativa to handle bounties] [...] Rejection of the code licensing basis is probably one of the reasons for some programmers not to join the project. This concerns as well JCA as LGPL (instead of preferred GPL), [...] [I don't agree that the GPL is preferred] [...] I didn't include all of the arguments mentioned on dev@de.openoffice.org (If you can read German, you could follow the thread here: http://de.openoffice.org/servlets/BrowseList?list=devby=threadfrom=1128834), but I hope I summarized the most important points. Hard enough to trying to summarize all this stuff :-) Thanks again. ciao Christian -- NP: Soulfly - Bring It - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Open Font License update
Hi Sophie, *, On Sun, Dec 18, 2005 at 11:14:16AM +0100, Sophie Gautier wrote: [...] For information, the version 1.0 of OFL (Open Font License) have been released and the first OFL-licensed font too, named Gentium. Do you know what changed compared to the draft you posted some time ago? see : http://scripts.sil.org/OFL http://scripts.sil.org/gentium Please don't hesitate to bring your feedback to the group or to Victor Gaultney directly, the license is still in work and there could be a 1.01 or 1.1 version. Hoorray! now that OOo has artificial bold (and italics) on linux as well (starting with m146), this font becomes even more usable than it already is :-) ciao Christian -- NP: Soulfly - Soulfire - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[native-lang] Re: [qa-dev] Issue 59169
On Sun, Dec 11, 2005 at 10:43:57AM +0100, Andre Schnabel wrote: could anybody from the asian (chinese?) community try to confirm issue 59169 http://qa.openoffice.org/issues/show_bug.cgi?id=59169 That is a wmf file that seems to be broken. display Pictures/20CEF821DB251B4E50D5.wmf ERROR: meta.c (179): wmf_header_read: this isn't a wmf file gimp Pictures/20CEF821DB251B4E50D5.wmf ERROR: meta.c (179): wmf_header_read: this isn't a wmf file OOo can open it though. To me it looks, like it is a regression, but I cannot tell if this is due to my environments (seems I have eastern fonts only on one of my systems). If it is a regression, please set the keyword accordingly. In OOo 2.0 it looks different (better), yes. But it doesn't look the same as in Word-Viewer though (partly because I don't have the font installed that is used in that wmf). But OOo 1.1.5 does a good job at the file, not perfect, but close. Please have a look at the priority as well. To me, this seems a rather rearely used type of document, so priority should be 3 instead of 2. I lowered prio to 3 because other apps could not open the wmf at all. ciao Christian -- NP: nichts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] list of major OOo deployments
Hi Louis, *, On Wed, Nov 30, 2005 at 07:19:52PM -0500, Louis Suarez-Potts wrote: I'm once again compiling my informal list of major OOo deployments and need help. I'd also like to make the list public and easily editable by community members, say by putting it on the Wiki, and have tentatively created http://wiki.services.openoffice.org/wiki/ Major_OpenOffice.org_Deployments .An IZ ticket would also work well. You may have a look at the list the german-language-project maintains: http://de.openoffice.org/marketing/referenzkunden.html While it does not only contain major deployments, it also conatains a section international that may be more in the way you had in mind. ciao Christian -- NP: Pantera - Shedding Skin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] [Fwd: [Marketing] mailing list guidelines]
Hi *, On Thu, Dec 01, 2005 at 12:31:19PM +0100, Charles-H.Schulz wrote: [...] Her explanations will also apply on the NLC list from now on. Original Message Subject: [Marketing] mailing list guidelines Date: Wed, 30 Nov 2005 18:26:22 +0800 From: Jacqueline McNally [EMAIL PROTECTED] [...] [...] Offending subscribers will be unsubscribed without notice. I absolutely do not like this part. Even when you're promoting a zero-tolerance politic regarding this topic, there must be at least a call to obey the rules before someone is kicked. Especially when one is banned without notice. [...] ciao Christian -- NP: Creed - Wash Away Those Years - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] OO.org 2.0.1?
Hi Vladimir, On Mon, Nov 28, 2005 at 08:18:46PM +0100, Vladimir Stefanov wrote: Today is the official date for version 2.0.1 and still nothing?! Today was the date for the RC. and the RC is uploaded. You'll find the current schedule here: http://wiki.services.openoffice.org/wiki/OOoRelease201 [...] ciao Christian -- NP: Metallica - Blackened - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Off topic question
Hi Vladimir, On Fri, Nov 25, 2005 at 09:30:06AM +0100, Vladimir Stefanov wrote: How to make OO to use Aspell for spell checking? OOo uses myspell (and will be using hunspell). myspell is a modified version of ispell that evolved to aspell. We have aspell for Macedonian language and AbiWord use it perfectly, but OO use Myspell, and we don't have Myspell for Macedonian language. The dicitonaries should be very similar. (and hunspell will be backwards-compatible to the myspell dictionaries). You'll have to convert the aspell-dicitonaries to the myspell-format. That format is very simple: First line: Number of entries (for speed-up, if not given then OOo has to read the file twice), the rest: one word per line (or base with affix-Indexes) So to get started, just dump your macedonian aspell-dictionary to a plain list of words. That is enough to get OOo work with it, although the file is not optimized yet. Use the command: aspell dump master macedonian | sort wordlist.dump to create the dump wc -l wordlist.dump will tell you the number of lines (=words) in the file. Just add that number as first line of the file. Then copy that file to xx_YY.dic (where xx_YY is the iso-code of the language_Country) Create an affix-file (xx_YY.aff). In its basic form, you only need two lines: First line: specifies the character-encoding. Second line: Specifies the letters to try when a misspelled word is found. Just count the letters in the wordlist and put them in the same order in the TRY-line (more often used letters first) Put the two files into the dictionary-directory of OOo and add a corresponding DIC-line to dictionary.lst After that you can start to optimize the wordlist (reducing the entries) by using the affix-mechanism explained in more detail here: http://lingucomponent.openoffice.org/affix.readme ciao Christian -- NP: Metallica - The Outlaw Torn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] How to delete a CVS folder?
Hi Konrad, On Wed, Nov 23, 2005 at 10:59:25AM +0100, Konrad Stobiecki wrote: Is there any way to delete a CVS folder? There is no way. I would like to delete the following with all files and subfolders: ./pl :) :P *joke* ./pl/src/images unused and copies ./pl/src/offline ./pl/src/!plooolite! ./pl/src/public If I can't do it myself, will you Charles or Louis do it manually, Deleting of directories is not supported by cvs. You can however specify -P when doing a checkout/update. This will remove all empty directories from your checkout. ciao Chrisitan -- NP: Hamlet - Versus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Click here to download the file / Kliknij tu aby pobrać plik
Hi *, On Mon, Nov 21, 2005 at 07:47:29PM +0100, Andre Schnabel wrote: Konrad Stobiecki schrieb: I would like to know how it goes in other languages: ENGLISH: Click this text to download the file POLISH: Kliknij ten tekst aby ściągnąć plik GERMAN: Klicken Sie auf diesen Text, um die Datei herunter zu laden. but please see http://www.w3.org/QA/Tips/noClickHere ciao Christian -- NP: Impaled Nazarene - Blood Is Thicker Than Water - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[native-lang] Please check whether issue 55738 occurs in your language as well
Hi *, cc reply-to [EMAIL PROTECTED] Bugs that are specific to builds in a certain language are rare (leave translation issues and issues because of different build-environment aside)... issue http://qa.openoffice.org/issues/show_bug.cgi?id=55738 is one of those. Please check whether your language is affected as well and if it is, make sure to check whether the fix in cws dba201e (when integrated) fixes the problem for your language as well. ciao Christian -- NP: Metallica - Frantic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Review of an Open Font licence
Hi *, On Mon, Sep 26, 2005 at 03:53:10PM +0200, Sophie Gautier wrote: Charles-H.Schulz wrote: [SIL] I received this mail that may be of interest for you too. It's about an open source font licensing project. I've met those people several times, last time this summer and I think that you could be of great help for them too. Yes, this is great news! [...] Besides, I have to say that although I've never heard of the SIL, it would be good to work more with this organization. What do you think? They are willing to work more with us too and I think it's a really good thing. May be Gentium (see http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiid=gentium) could be a first step if they release it under OFL ? Yes! I very much like that font and am using this font now for a couple of years. Very nice italics, but unfortunately no dedicated bold version They indicated in the mail you forwarded that they intend to oflify Gentium along with Doulos SIL (which is another great font, esp. when you need greek/cyrillic or IPA symbols) and some others. I would like to have opinions from others, because I'm not really a font user (arial is the best in my life ;) or in need of special fonts like some languages could have. SIL Fonts *rock* :-) - Especially for those languages that are not-so-wide-spread (in terms of high-quality fonts). Wheny you're into bible studies/hebrew, then have a look at Ezra SIL. See Galatia SIL for another greek Font... Regarding the proposed license, I cannot find anything that would conflict with OOo. As I personally don't care too much about the DFSG, it is perfectly OK for me that the license forbids selling the font (or derivates) itself (or in font-collections). It doesn't restrict selling of a bundle like OOo as a whole and that is what counts for me. I'm looking forward to it... ciao Christian -- NP: Raging Speedhorn - Death Row Dogs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] KDE keymap creation
Hi Murod, On Fri, Aug 12, 2005 at 09:24:56AM +0500, Murod Latifov wrote: I would like to have information regarding creating of keymaps for KDE3.x for utf-8. KDE or not doesn't matter. You create a keymap like you would with any other desktop environment. Any suggestion would be appreciated. As far as I know there is no keymap for tajik language in utf-8. UTF-8 doesn't matter either. Keymaps use symbolic names, not related to encoding. (hex-values of UTF-8 are possible as well). The encoding used in the keymap-file doesn't matter - it only has to be supported by your system. dumpkeys --help will tell you what charsets you can choose from. What locale you use for your system is not tied to the charset in the keymap file. AFAIK tajik uses cyrillic letters, so probably you should start with a russian keymap and modify that instead of starting from scratch. man keymaps gives you a detailed overwiev of how the file has to look and what you can do. The format is very similar to the one for xmodmap, so you can start by dumping your current map with xmpdmap -pke and create a modified map based on that one. ciao Christian -- NP: Rage Against The Machine - Bombtrack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] CTL, RTL and VTL
Hi *, On Thu, Aug 11, 2005 at 03:52:22PM +0900, Kazunari Hirano wrote: [...] I am not sure whether Japanese is CTL or STL. I wouldn't count Japanese to CTL-scripts. AFAIK Japanese has one glyph (graphical representation) for one symbol/character, whereas in CTL-languages the characters are modified either by accents or by context (where in the text does the character appear). And with accents in this case I don't mean stuff that simply is put above the other character like you would lay two transparent sheets over each other. But letter without accent looks like X whereas accented letter is displayed as Y. But that's only my interpretation... According to OOo's definition in the Help, RTL-languages are also counted as Complex Text Laout. But japanese is in a special group in OOo anyway (CJK/asian)... ciao Christian -- NP: Paradise Lost - Joys Of The Emptiness - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Arabic spellchecker
Hi Laurent, *, On Wed, Jul 20, 2005 at 04:44:17PM +0200, Laurent Godard wrote: I've been asked for an arabic spellchecker inside OOo it appears that nothing is available Do someone have informations if something is on the rails, if a MySpell/Aspell directory is available and be used aso I think the problem is to find a suitable algorithm to form the words. An arabic (I think it there is similar problems with hebrew) dictionary list would currently have to contain all possible forms of a word (or at least a big deal of them). myspell only works with prefixes/suffixes wich is not suitable for arabic. (Please correct me when I'm writing nonsense here) But this is no reason that there could not be an arabic dictionary-file. It just would be bigger... A quick search at google reveiled http://www.arabeyes.org/project.php?proj=duali an arabic spellchecker that uses a different affix-format but that could serve as a base for a myspell-compatible dictionary. Their cvs also contains a directory openoffice - maybe they're already working on integrating the spell-checker.. ciao Christian -- NP: Execution - Ocean (Out Of Control) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] new CCR - Laurent Godard
Hi *, On Tue, Jul 19, 2005 at 10:25:36AM +0800, Jacqueline McNally wrote: Laurent Godard is the new Community Council Representative winning with 53% of the total votes. Congratulations! [...] Twice as many people participated in the voting for the Community Council Representative (CCR) compared to the previous election. This is good news as well :-) ciao Christian -- NP: Manowar - Sting Of The Bumblebee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] IRC Talk starts now!!
Hi Charles, On Sun, Jul 17, 2005 at 01:45:04PM +0200, Charles-H.Schulz wrote: -I would like to ask Daniel to suspend for two weeks the IRC conferences, so that the incident of yesterday does not have any chance to reproduce itself. He will be free to restart them if he wishes too afterwards. -1 Why should the conferences stop just because one talk (and mainly not the talk itself) causes some controversy? And what is so bad about the points that bother lots of people get mentioned? (This is not the /how/ they get mentioned) ciao Christian -- NP: Metallica - Outlaw Torn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] NL project page administration
Hi Ain, On Sun, Jul 17, 2005 at 01:05:29PM +0300, Ain Vagula wrote: How can I adminstrate issue tracker subcomponents? What do you want to change? The description of your component? [...] NL project page templates are 3 years old, are they still suitable? Yes, they should be. You don't have to use them of course. I have many times read in this list that in list archives are answers to questions, how to localize projects main page sections, I have searched through archives but found nothing useful about localizing sections 'Search', 'How do I', etc. There is no easy way to localize these. While it is possible to use a different Label for the boxes, no project uses the translation-mechanism. You'd have to create a helmBundle_lang.properties file http://look.openoffice.org/source/browse/look/www/bundles/ Probably there would be more modifications involved. As I understand, there is no compact documentation about localizing NL projects main page at all?? Yes. Since basically there is not really mechanism to localize them. The only thing that I introduced to be replaced by the individual projects is the project-tools box. All other elements can however be hidden and replaced by custom stuff using css. See hu.openoffice.org for example ciao Christian -- NP: Metallica - Mama Said - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] IRC Talk starts now!!
Hi *, On Sun, Jul 17, 2005 at 02:05:41PM +0100, Daniel Carrera wrote: Christian Lohmaier wrote: Who will use GPL for documentation? Some people do. Perhaps this is not the best time to elaborate. Given that some of the posts lately have been a little heated. OK, then let's postpone the discussion. [...] Since the other licenses didn't fit the Debian Free Software Guidelines. The best people to discuss the why of the GPL for documentation is the debian-legal mailing list. The discussion there was very long and exhaustive. I wouldn't look forward to repeating it. I don't ask for repeating the discussion, I ask for the result. Why does the PDL not fullfill the DFSG? Furthermore: How useful is OOo-centric documentation for other people's documentation? If Debian decided to distribute the document, that would be useful. ? The point was reuse parts of the documentation in other documentation. Where is the realation to Debian in this case? it prevents distribution by Debian (the largest Linux distro), Why should it? This is one of the random, not clarified points. Because the PDL is not a free license according to the Debian Free Software Guidelines. It fails some of their tests. This is something that the debian-legal mailing list can explain infinitely better than I. Since you took part in that discussion, you could surely summarize the point where the PDL fails or at least post a pointer to the discussion. So why should it prevent distribution with Debian? Don't quote me on this, but I *think* it failed the isolated island test, and perhaps one more. I surely won't since I cannot find a reference to the isolated island test and don't know what this should be about. Google search for 'isolated island debian PDL' returns 0 results 'isolated island debian guideline' returns 0 results as well. http://www.debian.org/social_contract.html#guidelines doesn't mention island or isolated at all either. Another claim. What is the heavy work? Writing something like added chapter about XY, fixed typos, reworded XY? Is that enough detail for the purpose of the license? I don't know.Do you have to list every single change including page number, original text and the new one? That would be excessive. Don't you think this is absurd? At the other extreme, can you get away with reviewed the chapter and made edits? I don't know. Yes, in my understanding. If the changes are only technically/minor. It is a question of common sense. (What is the intention behind that clause) And the only way to find out is to get in legal trouble and have a judge decide. Suppose you make 50 edits to a chapter (that's not very much). No. It is not the only way. The only real way would have been to ask for clarification on that point, to either release an explanative add-on to the license or make a new revision of the license. ciao Christian -- NP: Metallica - Mercyful Fate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] IRC Talk starts now!!
Hi *, On Sun, Jul 17, 2005 at 04:15:29PM +0100, Daniel Carrera wrote: Christian Lohmaier wrote: I don't ask for repeating the discussion, I ask for the result. Why does the PDL not fullfill the DFSG? [snip] Since you took part in that discussion, you could surely summarize the point where the PDL fails or at least post a pointer to the discussion. Found it. Section 3.2 includes force distribution which failes the Desert Island test: http://people.debian.org/~bap/dfsg-faq.html http://lists.debian.org/debian-legal/2005/03/msg00236.html OK, I read it with emphasis on *editable* format, not on must publish, but this is another point that could be clarified by a new revision or similar. There was also a problem with section 3.3: http://lists.debian.org/debian-legal/2005/03/msg00260.html I don't this is a problem either. The 5-year limit applies when one tracks the changes using an electronic program like cvs. You cannot log the changes in CVS and the unplugg the server one week after the docs are published. (Well you can uplugg it but then you have to provide the logs elsewhere) [...] But no matter. It looks like you and Ian came up with a good alternative. Let me explore that before we keep dwelling on this. OK. ciao Christian -- NP: Hamlet - El disfraz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] NL project page administration
Hi Ain, On Sun, Jul 17, 2005 at 04:28:29PM +0300, Ain Vagula wrote: On 7/17/05, Christian Lohmaier [EMAIL PROTECTED] wrote: On Sun, Jul 17, 2005 at 01:05:29PM +0300, Ain Vagula wrote: How can I adminstrate issue tracker subcomponents? What do you want to change? The description of your component? No, subcomponents list. I have at the time only 'www' listed. I expect most issues to be about GUI or OLH translation, so I'd like to have according subcomponents. I'm not sure whether this is can be configured by the individual project leads. I'd file an issue against issueZilla asking for the new subcomponents. [...] There is no easy way to localize these. While it is possible to use a different Label for the boxes, no project uses the translation-mechanism. You'd have to create a helmBundle_lang.properties file http://look.openoffice.org/source/browse/look/www/bundles/ Probably there would be more modifications involved. Thanks, I'll look at this. As I understand, there is no compact documentation about localizing NL projects main page at all?? Yes. Since basically there is not really mechanism to localize them. Sad. Does this mean, that project web interface, provided by CollabNet, does not support internationalization, like many others do? It does (see above), but it is not used on OOo. Many pages can be localized. (when you encounter a file file.htm.html this is the fallback, file.en.html would be the version for english, etc.) But again: This stuff is not used and probably it takes more than just to create the files. ciao Christian -- NP: Sepultura - Attitude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] IRC Talk starts now!!
On Sun, Jul 17, 2005 at 08:33:00PM +0100, Daniel Carrera wrote: Christian Lohmaier wrote: OK, I read it with emphasis on *editable* format, not on must publish, but this is another point that could be clarified by a new revision or similar. [snip] I don't this is a problem either. The 5-year limit applies when one tracks the changes using an electronic program like cvs. Ultimately it doesn't matter what you and I think. That is not my point. If the license is not clear, one should try to clarify it, not lay back and just pick something else. It's what Debian thinks. They get to pick what counts as DFSG-free. It's just one of those things that we can't do anything about because Debian is very carefuly designed so the notion of freenes can't be compromised. So all we can do is shrug and accept their veredict. What about not taking care of what Debian thinks? Debian is not /the/ institution that defines free. Let them fight their crusade. What about trying to resolve the issues so that the PDL clarifies as DFSG free? The points are minor and only a matter of interpretation. ciao Christian -- NP: Linkin Park - Points Of Authority - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Re: [documentation-dev] Re: [native-lang] dropdown and HOW TO
Hi *, On Sat, Jul 16, 2005 at 01:32:41PM -0400, G. Roderick Singleton wrote: On Sat, 2005-07-16 at 17:03 +, Jonathon Blake wrote: GRS wrote: you sent them to the wrong place; hence the rejection. If they were sent to the wrong place then that is because the documentation said to submit them to the wrong place. You know I cannot say I understand this. You claim you have submitted stuff yet I can find no record of it. There is no record. Jonathon likes to make false claims and when one points out that he is wrong, he doesn't answer but starts picking about bad english. I plonked him for this reason. Just refer to http://documentation.openoffice.org/servlets/ReadMsg?list=devmsgNo=2280 and the whole thread http://native-lang.openoffice.org/servlets/ReadMsg?list=devmsgNo=4908 and thread and finally: http://native-lang.openoffice.org/servlets/ReadMsg?list=devmsgNo=5242 and thread. [...] ciao Christian -- NP: Limp Bizkit - Let Me Down - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] OpenOffice.org 1.1.5 Release Candidate Is Here
Hi *, On Fri, Jul 15, 2005 at 10:48:41AM +0800, Jacqueline McNally wrote: Andre Schnabel wrote: Hi Jacueline, all, Von: Jacqueline McNally [EMAIL PROTECTED] [...] I think we need to be a little more precise with our wording. I just take wikipedia as reference, as it tells, what most people think, what a RC is: http://en.wikipedia.org/wiki/Release_candidate#Release_candidate The term release candidate can refer to a final product, ready to release unless fatal bugs emerge. ... for versions that are substantially complete, but still under test, ... for final testing of versions that are believed to be bug-free, and may go into production at any time. This definition works well if there is a finite group working on the release cycle. But here, and with other OSS, everyone has the opportunity to be involved in the progression of the software through its release cycle. That's nonsense. This definition works well with software and communities of every size. Before the RC, there are snapshots, alphas, betas. This definition is also what has been the guideline within OOo all the time. That the assumtion ready for production use turned out not to be true in some cases is a totally different thing. And your statement everyboy can be involved has nothing to do with the definitionn of a RC and has nothing to do with what we release as RC. So, at this time, we *know* that our RC is not ready to be released. A showstopper has been raised yesterday at the releases list. It has already been marked as fixed, so I'd expect to see a new RC within the next few days. Yes, we will, so we will have another one. But don't you think it is better that many more people are able and willing to download and test the releases that are not yet production ? No. Not when it is a release candidate and the main way of installation is broken. Measured and experienced testers are vital, but end-users that are willing to give it a go are also invaluable as they often do things in a way that is difficult to include in regression and smoke tests. Endusers that will experience Problems during install will not likely be willing to give it a serious look. Everybody else knows about the RC anyway - be it through monitoring the mirrors, reading the releases or qa-list, some news-site mentioning it. We should not officially announce a RC that is broken. [...] ciao Christian -- NP: Pantera - (Reprise) Sandblasted Skin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] [Test] FontOOo Japanese version
On Wed, Jul 06, 2005 at 01:42:33PM +0900, NAKATA Maho wrote: In Message-ID: [EMAIL PROTECTED] Christian Lohmaier [EMAIL PROTECTED] wrote: Another set of fonts is available from http://www.i-love-epson.co.jp/ http://www.i-love-epson.co.jp/download2/printer/driver/win/page/ttf30.htm Hope you understand EULA written in Japanese. it is almost impossible to use these fonts. No, I don't... I stumbled over the link somewhere and it read free download (other fonts were listed as restricted or shareware or comes with $product, so I assumed they were free to use (I didn't download the Epson-font myself) What does the EULA say? ciao Christian -- NP: nichts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] [Test] FontOOo Japanese version
Hi Laurent, On Sun, Jul 03, 2005 at 08:48:55PM +0200, Laurent Godard wrote: ..What about using FontOOo to download a font that contains the missing characters? ;- yes, why not ;) any name ? Good counter :-) Seems like FontOOo doesn't know about those yet... Here are some: Kochi Gothic Kochi Mincho Sazanami Gothic Sazanami Mincho Y.OzFontN The Kochi and Sazanami Fonts can be obtained from http://sourceforge.jp/projects/efont/ The Y.OzFontN is available here: http://yozvox.web.infoseek.co.jp/ Another set of fonts is available from http://www.i-love-epson.co.jp/ http://www.i-love-epson.co.jp/download2/printer/driver/win/page/ttf30.htm ciao Christian -- NP: nichts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] [Test] FontOOo Japanese version
Hi Laurent, On Sat, Jul 02, 2005 at 11:20:19AM +0200, Laurent Godard wrote: [...] I can't see if all is correct as i don't read any japanese and even do not have the fonts (the autopilot remains written with a lot of rectangles event with asiatic language support...) ..What about using FontOOo to download a font that contains the missing characters? ;- ciao Christian -- NP: Linkin Park - Nobody's Listening - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Re: [dansk] Re: separator issue solution
Hi *, On Wed, Jun 29, 2005 at 07:35:39PM +0200, Søren Thing Pedersen wrote: Charles-H.Schulz skrev: this is how I see the situation. Several builds are affected by this separator issues. But others are not. Applying your patch to all the builds (i.e to the core) will break not just compatibility with former SO 5.2 documents, Very wrong. Any change in this are will not affect already existing documents. [big snip] ciao Christian -- NP: Helloween - Don't Run For Cover - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Local menus
Hi *, On Sat, Jun 25, 2005 at 02:31:09PM +0200, Søren Thing Pedersen wrote: I recently visited the Norwegian site no.openoffice.org and learned how to integrate the local menu in the left menu. All that was announced several times in various mailing-lists. Inlcuding this one and the project-leads list. [...] ciao Chrstian -- NP: Metallica - The Call Of Ktulu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] LinuxTag in Germany
Hi *, On Fri, Jun 24, 2005 at 08:21:26PM +0200, Aiet Kolkhi wrote: could you please mention here if your NL will be repersented on LinuxTag in Germay? German-lang project is present: booth F89 in der Gartenhalle http://de.openoffice.org/veranstaltungen/linuxtag2005/index.html ciao Christian -- NP: Limp Bizkit - Underneath The Gun - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Update: Sun/NLC meeting
Hi *, On Tue, Jun 07, 2005 at 05:18:53PM +0200, Joerg Barfurth wrote: Christian Lohmaier wrote: On Fri, Jun 03, 2005 at 12:33:34PM +0200, Joerg Barfurth wrote: For the second point: it is tedious to do this, but the rfe_eval flag/process can be the vehicle to do it. But why do you spend time on something that leads to nothing? How do you know that it won't? That was not a statement that it would lead to nothing. But this is the impression I and others got. If you see zero progress (really zero, nothing at all) you conclude that it is not worth spending time on this effort since your contribution doesn't speed things up. Again this may not be true (and I hope it is not) - but this is the state as of now. This is the big problem why evaluating (=quality controlling) of the RFE-process has stalled. I can see that you'd like faster responses. But apparently that is not the way Sun UE organize their work. And that is why a new process was introduced. That is why I made the review-proposals even before that new process was introduced. But the new process did not help at all, it did not change the handling of RFEs. So why should this new process be useful? Meanwhile presorting and enhancing RFE issues is the one thing you can do to prepare things for the time when RFE processing is resumed. But this is not the goal of a RFE-process. This is just general qa-work, nothing special to RFEs. I don't want to evaluate 2000+ issues only to have 1800 of them ignored again. Which is sort of dangerous. I know that queries for 'no target milestone assigned' are sometimes used to find issues that need this kind of evaluation. In the case of RFEs no TM has been processed at all in the meantime. Again: I don't know how Sun UE organize their work and have no influence on that. Nobody knows. But again: UE doesn't set the target-milestones. UE doesn't respond to issues. I also don't know what 'in the meantime' refers to. In the meantime: After planning for OOo 2.0 has ended up until now. You can take from the very beginning of IssueZilla until now as well since only few issues reported by regular users have been processed by user-experience during planning. Most of them were handled after planning finished and the issues matched by accident. But if I were in UE, I'd start by looking through issues without target milestone (to decide between next release, Later, PleaseHelp and WONTFIX). Again: This decision is not being taken at all. Again: When I write no action, no decision at all, I really mean no decision at all. [...] As you write: You're not UE and cannot influence this. [...] OTOH, waiting for super-reviews used to be one of the main bottlenecks in contributing to mozilla, iirc. AFAIK auch a review was necessary for every contribution, every patch to assure the quality of the code (not to break other things). This whole area is covered by CWS-QA in OOo. I probably meant that if stuff is now stuck assigned to requirements, it might then end up waiting for super-review. So it all makes sense only if you find suitable super-reviewers that are willing to make this a success. No. It makes sense to only apply the review-process to a selection of issues. That's why there is a first review-step to sort out the issues, to reduce that number to a reasonable value. Again: It would be a progess if UE would decide upon one issue per month. The review-thing is *not* meant to be the standard way of handling issues. It is meant to get a handful of issues handled faster than others (or have them hanled at all). True. But this already happened to a degree. But we have (or had?) very long designated feature or UI freeze phases. And in those phases - and even a certain time before the deadlines - little room for decisions remains. Nobody said that you have to consider the issues for the current release. Apparently that is the way the UE people work: they only look over issues when there is a release they could put it into. But you know there will be a release after the current one. [...] OTOH, if we take community RFE work seriously, why couldn't the evaluation and classification be done by 'community RE'? It is only the *we* (Sun) will/may/won't do this part that requires decisions by Sun. That is what the whole process is about, but Sun doesn't take this decision. And these decisions are very much driven by resources and internal goals for the next release(s). And where's the problem in taking this decision before the current release is out of the door? Try changing/influencing it *before* feature/UI freeze! The issue was filed before UI freeze! (june 2004) Which one? The quickstarter one. The other issues I mentioned were filed *way before featurefreeze*, they were filed against OOo 1.1.0 or even against earlier versions. [...] Where do I say that this is internal? In our process the i-Team is responsible
Re: [native-lang] Update: Sun/NLC meeting
Hi *, On Fri, Jun 03, 2005 at 11:13:24AM +0200, Joerg Barfurth wrote: Christian Lohmaier wrote: On Thu, Jun 02, 2005 at 03:54:31PM +0200, Joerg Barfurth wrote: Christian Lohmaier wrote: [OOoPleaseHelp-Issues] That is exactly the idea behind closing it. Get it out of the way, leave the issues that are being worked on/that have not yet been decided upon. There are many different roles in this project, which do different things with existing issues. Some examples 1. Look for existing issues a) before submitting an own one b) during evaluation 2. Confirm, evaluate and dispatch new issues 3. Look for issues to implement a) during release planning b) as independent developer 4. Plan and track your development work 5. Track the feature status/quality of releases in progress In this selection each task has a different set of issues with which to work. The issues we are talking about are not at all relevant only for 2. and 4. They are very relevant for both 1. and 3b). These two tasks are often done by newcomers with limited experience in dealing with issuezilla. Thus our issues really should not be closed and should even be included in the default queries. I disagree. With the same reasoning you shouldn't close fixed issues or duplicates (for 1). Furthermore: I as independent developer would just query for OOoPleaseHelp, no solutin necessary. I can be sure that I don't duplicate any work and that the work I'm going to make will be accepted for the product. This is not the case for unevaluated issues. Regarding 4) This task is done by a small group of people. Have them use a dedicated saved query instead of forcing every else to do so. For 4) A catch *all* issues that match if far more likely than the average query that limits the results to issues containing summary/description. Same goes for 5) If you regularly do activities like 2. and 4. you probably will set up saved queries adapted to your needs anyhow - so excluding issues having the 'OOo PleaseHelp' target or marked RESOLVED/LATER would be trivial. Otherwise you can still easily adopt the habit to deselect it every time. Saved queries only help partially - if you want to query for varying summaries/descriptions a saved query is far from usable (with dial-up connection). Loading a query is just too damn slow. The only way to work with IssueZilla and lots of different queries is to use your browser's cache in this case - and this only works with one standard-query. Having a look at the list of target-milestones you'll notice that deselecting it is not that trivial. It is annoying sice you'll always have to scroll the list and to spot the entries you don't want. It might be assigned to a dummy owner and/or we might use the useless RESOLVED-LATER status for it, but we should not close it. I disagree, mainly because of working on the open issues gets easier when the issues that nobody's working on are not in the way. If a developer looks for issues he could take on, he will look at things that are still open, rather than closed (i.e. dealt with for good). From my understanding (Sun-paid) developers don't look for issues on their own, they take the ones assigned to them by UE. Since UE already has decided that this is something that is not appealing for Sun to do by itself, they don't have to bother with those issues. Independent developers have a singe thing to look for: The OOoPleaseHelp-target. If they want all, they can setup a dedicated query that defaults to both or adapt an existing query for their current session. Looking for issues to implement is far less usual than looking for issues because of other reasons. If you don't close them, you'll have to exclude the target OOoPleaseHelp in every query again and again.. It depends on the goals of your query. And yes, the initial query defaults in issuezilla will not suit every role. Yes. And I say: It is far easier to have the few people to have special queries than to force the majority to do so. The most important characteristic of such an issue is that - it is OPEN - it has target milestone OOoPleaseHelp My opinion is: Open issues are those that some action is going to be taken. Open issues are those on which some action may be taken. Closed issues are those on which no action will be taken any more. If you have a current issue that looks duplicate to a closed issue you should generally submit a new one. The closed one is done. So where you see the difference? Don't confuse the TM with the keyword needhelp. The OOoPleaseHelp-issues are de-facto dead. Unless someone picks it. In this case it is reopened - worked on. Unless the situation changes and picking such an issue for implementation gets the usual thing (instead of nobody working on it), then the policy can be changed to leave those issue open. But if only 1 issue out of 300 OOoPleaseHelp issues get worked on, closing them is more honest
Re: [native-lang] Update: Sun/NLC meeting
Hi *, On Thu, Jun 02, 2005 at 01:48:12PM +0200, Charles-H.Schulz wrote: [...] As a side note, it seems to me that these issues could best be handled by the ESC. I hope this will be efficient in dealing with these issues. If an issue is marked as wontfix by Sun, any developer/company should be able to work on it and contribute its implementation/patch back to the central trunk or at least leave it on a cws until a final decision has been taken. No, better agree on consisten usage of the resolution. wontfix should mean: Not possible at all due to technical reasons and/or issue will not be incorporated even when a patch exists (product policy/strategy, legal issues, etc.). So it doesn't really make sense to work on it before the situation is cleared in the second case (don't want this in the product) unless you want to maintain a patch-set against the original sources... issues that won't be dealt with by Sun because of workload, bad effort/gain ratio, of no interest because StarOffice has commercial replacement, ... (We won't implement it, but just go ahead and povide a patch) should not be closed wontfix but worksforme with TM OOoPleaseHelp (unless there is a dedicated resolution for this kind of stuff) ciao Christian -- NP: Helloween - Twilight Of The Gods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Update: Sun/NLC meeting
Hi *, On Thu, Jun 02, 2005 at 03:54:31PM +0200, Joerg Barfurth wrote: Christian Lohmaier wrote: On Thu, Jun 02, 2005 at 01:48:12PM +0200, Charles-H.Schulz wrote: [...] issues that won't be dealt with by Sun because of workload, bad effort/gain ratio, of no interest because StarOffice has commercial replacement, ... (We won't implement it, but just go ahead and povide a patch) should not be closed wontfix but worksforme with TM OOoPleaseHelp (unless there is a dedicated resolution for this kind of stuff) I don't agree that they should be closed. An issue that is closed to me is gone. I would exclude it from any queries, except post-mortem statistical evaluations. That is exactly the idea behind closing it. Get it out of the way, leave the issues that are being worked on/that have not yet been decided upon. It might be assigned to a dummy owner and/or we might use the useless RESOLVED-LATER status for it, but we should not close it. I disagree, mainly because of working on the open issues gets easier when the issues that nobody's working on are not in the way. If you don't close them, you'll have to exclude the target OOoPleaseHelp in every query again and again.. The most important characteristic of such an issue is that - it is OPEN - it has target milestone OOoPleaseHelp My opinion is: Open issues are those that some action is going to be taken. To me it doesn't make sense to have issues open that nobody is/will be working on. Leaving it open may signal to the reporter that the issue is handled. Closing it makes clear that unless someone interested takes care of the issue, it will never see the light of day. Closing it with an appropriate comment may even result in the reporter searching for independent developers actively while such pressure is not createn by leaving the issue open and letting it rot... ciao Christian -- NP: Linkin Park - Papercut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Update: Sun/NLC meeting
Hi *, On Thu, Jun 02, 2005 at 05:39:37PM +0200, Joerg Barfurth wrote: Christian Lohmaier wrote: On Wed, Jun 01, 2005 at 04:39:34PM +0200, Joerg Barfurth wrote: Christian Lohmaier wrote: [...] 1) Is the handling in issuezilla that currently lacks significantly. Not on the QA-part of it, but on the decision side. What exactly is lacking there? The most important source of information about this kind of decision is the target milestone. This kind of information is useless since almost all RFEs have the TM OOo later or --- which can be excachanged by each other without any loss of information. That shouldn't be the case. Before assigning any target milestone an initial round of triaging should have taken place. Thus issues that are incomprehensible, unacceptable or known to be duplicate should be closed as INVALID, WONTFIX, WORKSFORME or DUPLICATE without ever getting a target milestone. I was only talking about issues in status New Features/Enhancements with status New: ---: 1654 OOoLater: 1104 Between these two targets, ther is basically no difference at all. The same goes for not determined. It depends on the one who reassignes the issue on what target the issue will have. To me target milestone OOo later signifies that the issue is basically accepted as should/could be implemented, but that noone has comitted to working on it for one of the active releases. This is true for defects, but not for RFEs (at least not in practice). If this does not correspond to current TM assignments, then - Either this accumulated historic cruft or Yes, some of the targets were not available all the time. - Our target milstone definitions are not clear enough or - Our target milestone usage has not been communicated well enough I cannot tell what the reasons is, I can only tell that I cannot determine any difference between these target milestones when it comes to RFEs. The use of not determined is certainly underspecified. I can think of at least two vastly different meanings. True. I for myself used that milestone for issues that I evaluated according to the new process, hoping that the evaluated issues would get handled sometime soon and get a real target (or rejected) But some clarification would be welcomed. [...] In many cases there simply are no decisions yet - except that the feature is not considered for the currently active release branches. Yes! And that is exaclty the problems: No decisions. Right. And my answer is: to get faster decisions, we need shorter release cycles. No objections from my part.. [...] The qa-Project is ready. What is needed is a process on how feedback on the specs will be handled. (Here I come again with my review-system...) http://qa.openoffice.org/servlets/ReadMsg?list=devmsgId=1058032 http://marketing.openoffice.org/servlets/ReadMsg?list=proddevmsgNo=79 That might make sense. But apparently the proposal did not reach the right people (yet). Given the fact that I came up with this a couple of times and mailing lists (including the dedicated proddev-ML) I doubt it wil reach the right people ever. Generally I'd think exchanging mail with the i-Team and/or the relevant dev@project list is the way to provide feedback. It then depends on the i-Team members what they do with the feedback. Systematically we can provide guidelines or recommendations for dealing with feedback but ultimately the team takes the decisions. You mentioned the problem that votes on issuezilla and of feedback by individuals would not be representative of the user-base. A set of reviewers (e.g. representatives of the native-lang-project) would certify with their approval that the issue is important - not only for a handful of noisy individuals, but for many,many people. Still the ones who do the work are free to do with the feedback what they want. Sure. The only idea behind all this is to get a *timely* response. Again: All about decisions, not about the implementation or the implementation timeframe. So we are back at the need of an appeal process to an authority that is entitled to overturn decisions by individual developers. That is handled by vetoing. Wrt. vetoing: yes, we probably need a defined process to appeal/escalate arguments to project leads, CC or ESC. here the review system again. The initial idea was that it should accelerate getting a decision on lousy to fix RFEs, bypassing the product-planning phases. The reviewers should make sure that the issue really qualifies for an accelerated decision (small impact, really lousy to fix) - But the same system can be applied to vetoing. For vetoing you need someone or some group that has been given the authority for such decisions. This could be ESC, CC or project lead(s). I don't think a 'veto' by a loosely defined band of reviewers would be considered authoritative by a developer. You missed
Re: [native-lang] Update: Sun/NLC meeting
Hi *, On Thu, Jun 02, 2005 at 05:36:00PM +, Jonathon Blake wrote: Christian wrote: It might be assigned to a dummy owner and/or we might use the useless RESOLVED-LATER status for it, but we should not close it. I disagree, mainly because of working on the open issues gets easier Why not have flags that indicate one of the following: Because flags are often not that obvious. And when there are too many flags, then people won't use them properly. i) Feature can not be implemented because of coding problems. ii) Feature will not, under any circumstances be implemented by Sun. iii) Feature not cost effective for Sun to implement. Furtheremore the categories you describe won't fit and ii) and iii) don't really make a difference. But most important: Flags don't ease the issue-handling of the other issues. Those OOoPleaseHelp-issues would still be in the way or have to be deselected everytime. With flags this is even more difficult. Closing it with an appropriate comment may even result in the reporter searching for independent developers actively That will happen if, and only if the reporter has an understanding of why the issue was closed. Sure. The best policy is useless if people don't follow it. - But this is true for the flags as well... Setting these flags (and thus putting this issue on hold until someone grabs it) without giving an appropriate comment won't help either. [...] ciao Christain -- NP: Sepultura - Roots Bloody Roots - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Update: Sun/NLC meeting
Hi *, On Thu, Jun 02, 2005 at 08:56:05PM +, Jonathon Blake wrote: Christian wrote: Because flags are often not that obvious. Irrelevent. Sorry? If nobody understands what the flag should mean and when to apply it how could this work? We already have many items in issuezilla that are not used as intended. People compain that IssueZilla is too complicated, that it offers far to many choices. [...] But most important: Flags don't ease the issue-handling of the other issues. Those OOoPleaseHelp-issues would still be in the way or have to be deselected everytime. With flags this is even more difficult. They can be used as alternatives to OOOoPleaseHelp, or go back and be used as neither open, nor closed. Then the same thing applies: It is hard to exclude those from a query, you'll always have to deselect them. And what do you mean with go back [...]? [...] A flag that says sun refuses point blank to implement this feature even if lacks no other explanation, is a lot more useful than the current setup where things are either closed, or reassigned, and left in limbo, even though sun won't ever do it. Did you read my previous posts at all? ciao Christian -- NP: System Of A Down - Suggestions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Update: Sun/NLC meeting
On Thu, Jun 02, 2005 at 11:02:27PM +, Jonathon Blake wrote: Chrisitan wrote: [...] And what do you mean with go back [...]? I was quoting you there. I never wrote go back ... Did you read my previous posts at all? Did you comprehend what I wrote? Again you're demonstrating your unwillingness to have a serious conversation. I'm not interested in your silly games. EOD. ciao Chrisitan -- NP: System Of A Down - Suggestions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Update: Sun/NLC meeting
Hi *, On Fri, May 20, 2005 at 04:10:32PM +0200, Joerg Barfurth wrote: Sophie Gautier wrote: I join Christian here, it's not about getting feature implemented but influence the decisions that are taken. [...] It is hard to find the right level at which this can happen and where this separation is possible. The decision how much effort should be put into a feature can't really be separated, but that decision in turn is strongly interrelated with decisions about the feature itself and what shape it should take on a high level. These are two things. 1) Whether the feature is considered at all and 2) How the actual design of the feature will be I think it is absolutly necessary to involve the community in step 2), once the decision is taken. On 1), there's nothing the community can do, Sun pays for it so Sun decides where to spend its ressources. 1) Is the handling in issuezilla that currently lacks significantly. Not on the QA-part of it, but on the decision side. OTOH many detailed decisions can only be taken when there is a solution design and maybe even a prototype, which means that the decision to address the feature has been taken already (otherwise who would do the work on the design or prototype). When a prototype or whatever information is missing the situation is the following: * the issue just sits there forever (like the other ones) But it should be like this: * people should be asked to provide the necessary information, spec, etc.. [...] As for EIS where informations about QA are missing, we need also to be aware where and when we can intervene and when and where we can't. Understanding this probably requires a deeper understanding of the development process. I believe this was not very easy in the early stages of the OOo 2.0 release cycle. But thing should have improved since. We now have the CWS (child workspace) process open to community developers, so the way things get implemented is visible and documented for the non-Sun community. The problem is not the actual programming work - this has improved much. The problem still is * getting decisions (no visible reactions on RFEs in issueZilla) * listening to/getting/asking for input from the community on the specifications The problem is that most of the feedback on the specs arrives once the feature appears in the product since nobody really knows about the spec beforehand. (This may improve once this is stated more prominently). There should be a way to influence these design bugs more easily (not by having such a big fight like for the quickstarter entries). Participating in this also requires a QA process that integrates the community QA and possibly a process to do early (pre-integration) feedback releases from child workspaces. Both of this isn't really there yet. This is probably something the qa project should try to set up. The qa-Project is ready. What is needed is a process on how feedback on the specs will be handled. (Here I come again with my review-system...) But if you want to influence design decisions, this will probably have to start earlier, which means were are back at the RFE and specification process. If you mean with design the direction the product is heading to, then no, the community doesn't need to be involved. It is Sun's decision on what it will implement and what things to reject (but again it should communicate the decision). If you mean with design shaping the implementation of that paricular feature, then yes, the community should be involved; it should have some kind of veto. [...] oups, I was not aware of that. We have begin to work on RFE process some time ago now and nobody told me that it was postponed after 2.0. Anyway I have postponed my participation because nothing was moving at all. Not sure if this was a formal decision. This was just my impression, but I really have nothing to do with the RFE process myself. I noticed that progress on the RFE process was stalled It basically never started from Sun's (decision-taking) part. That's why the evaluation of the RFEs slowed down. Without getting the decisions on the issues the whole process doesn't make any sense. It is just shoveling the issues from one pile to another (reassign from bh to requirements). The only advantage of the process is that those issues got looked at at all, that the issues with rfe_eval_ok have a clear description. But that's all that was achieved. [...] I was really referring to participating in designing a RFE process. I have not heard of process suggestions being turned down because the proposer is not representative. Well, I tried, but a process doesn't help if it is not followed. Of course such a process will have to deal with the fact that any given RFE may not be good for all users and that anyone who implements features (e.g. Sun) will value the perceived needs of their target group higher than those of the
Re: [native-lang] project_tools.html on staticized pages
Hi *, On Sun, May 15, 2005 at 12:37:44PM +0100, Sophie Gautier wrote: Christian Lohmaier wrote: On Sat, May 14, 2005 at 07:18:53PM +0100, Sophie Gautier wrote: [...] yes, I really mean the right navbar, even if it's in my html file I would like to test having it integrated at the left side. OK. If you want the default formatting, then you can use the navbar of api.ooo as an example. Basically it is div class=labelstrongThe Heading/strong/div div class=body divLink1/div divLink2/div /div div class=body divLink3/div divLink4/div /div The body divs will be seperated by a vertical whitespace. To create subpoints, simply nest the divs: div class=body divLink3 divSublink1/div divSublink2/div /div divLink4 divSublink3/div divSublink4/div /div /div But you don't need to stick with the default formatting, you can put other formatting in there as well. [...] ciao Christian -- NP: Samael - 'Till We Meet Again - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] project_tools.html on staticized pages
Hi Sophie, *, On Sat, May 14, 2005 at 07:18:53PM +0100, Sophie Gautier wrote: [...] Christian : On this topic (or not far from it) I'm trying to change the FR site using css and to get rid of the right navbar. Really mean the right navbar? This is what you have in your html files... In your case you cannot simply hide it using css since you specified the formatting directly in the html and did not use some id or class that can be referenced in a css-statement. So to get rid of it either * delete it * add an id to the navbar-table and set display:none for that id * encapsulate the navbar with a div that has an id and hide the div. For this, before doing something, I'm trying to understand the page you've made for the DE project on sc40. I'm a bit lost, I might not be a css girl ;) The pages on sc40 were just copied over from the live site and then I changed the css ID of the navbar-table (because I copied the navbar to project_tools.html for testing) to not have two items with the same ID. Do I have to add this adapted for FR on my pages instead of the usual header : No, if you don't want have this stuff, you don't need it. (Esp. the comments are optional as well, but it helps to identify your statements in the final page) !-- Start de-header -- link rel=stylesheet href=styles/de.css media=screen type=text/css / link rel=stylesheet href=styles/de_print.css media=print type=text/css / link rel=stylesheet title=mit Navbar href=styles/de_navbar.css media=screen type=text/css / link rel=alternate stylesheet title=ohne Navbar media=screen href=styles/de_nonavbar.css type=text/css / !-- Comment to test HELM-parsing $helmR.getServletName() -- esp. this comment was for testing the staging server. Don't add this to your html. meta http-equiv=Content-Type content=text/html; charset=UTF-8 / !-- Kommentare zur Seite $Id: index.html,v 1.6 2005/04/11 17:53:36 cloph Exp $ The above gets updated by cvs automatically, so you always know who did the last change to the file (and when). This doesn't need to be placed inside a comment but can be a regular text as well. -- !-- End de-header -- I'm not sure to remember well, but do we have a style sheet per project somewhere on SC ? No, this is not defined globally. You define this in the file in cvs. (You know, nowadays you have complete html-pages in the repository, not only the body like it was the case in the beginnings). So if you have a head-section and put your link statements there, they will be recognized by sourcecast and incorporated in the final page. So to include your project's stylesheet add the line link rel=stylesheet href=your/style.css type=text/css / to your html... We have an alternate stylesheet that hides our right navbar because some pages with large tables need some more horizontal space... If you don't need/use an additional stylesheet, you don't have to specify it. I see your html-code still has this comment... !--Start here. Do not add any header HTML-- but this is now longer necessary - feel free to add header statements (as a title-attribute or stylesheet information) ciao Christian -- NP: Meshuggah - Terminal Illusions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Update: Sun/NLC meeting
Hi Jörg, On Fri, May 06, 2005 at 12:22:03PM +0200, Joerg Barfurth wrote: Andre Schnabel wrote: As Christian already said .. we *are* helping, some of us *did* go through the RFE process (I never did, as I've foreseen, what would happen). But sometimes it seems, our help is not wanted. It is my impression that the RFE process never took off, because it was too late for OOo 2.0. And not much has happened since the initial ideas were floated, because 2.0 is still not out and most work still goes there. Noone expected the process to have influence on OOo 2.0 And furthermore the whole thing is not about getting the features implemented, but getting decisions. OOo 2.0 had one big step forward in handling planned changes by making most of the work public. It was a step forward, but this had absolutely no influence on handling RFEs in issuezilla. The 'Q concept' was published, specs were published and announced So where are these specs announced? It doesn't really help if the final spec gets announced. - sometimes well before implementation and most feature issues were entered in IZ instead of the Sun-internal bug tracking system. This already would have allowed community participation, but it was not explicitly solicited. It is my impression that this opportunity was not used very much. Again: These doesn't help regarding the handling of the issues as these issues already have had a decision. Furthermore: you have virtually no chance of hitting such an issue with a query (only if you know the magic word Q-PCD) - the summaries are non-telling. And even when one stumbles across one of these and reads a spec.. Why should one expect to be listened to if even the comments from developers are ignored? (Just take the spec regarding the (non-)saving of the last cursor position). And BTW: Most of those long-term-Features are not the problem. The problem are recently changes things. But again: These are different (although related topics). 1) handling/processing the issues 2) having influence on the actual implementation of an issue 1) has always been a problem and has not improved at all since the beginning of OOo. 2) has been a problem lately since major changes in usability were done and there was no process/no way to veto the changes. This in fact still is a problem. People are trying to change the spec, but Sun's people don't listen/are not willing to correct mistakes. Some examples: * quickstarter * mail-merge * cursor-position * line-breaks in justified paragraphs * change of defaults (compatibility options) * printer-configuration * toolbar-blinking of docked, contextual toolbars * [...] some are resolved, others are not. The quickstarter-issue was a huge fight, the toolbar-issue is in the works (not that hard to get a correction this time), the others (esp. the line-break one) are negated/not taken seriously (old behavoiur was a bug). I'm sure that the qa-engineers know about the duplicates, but still they close them as Wontfix. I cannot tell (and don't want to judge) whether this is bad will (for the statistics) or just laziness (don't want to look-up the other issue). What I want to say is: These are urgent problems and they have to be considered *now* and not for OOo 3.0 [...] What did you foresee would happen with the RFE process? Just answer this little question: What is the difference between having 600+ issues assigned to bh and 600+ issues assigned to requirements when the last action of all those issues is reassigned to bh/requirements? My wishes: * way to escalate issues for the current version * getting decisions of other issues in a timely fashion. Having untouched issues that are 2 years and older (without *any* action at all) really sucks. AFAICT the plan was to implement a better RFE process for the release after 2.0, and this is still possible and you can participate in making that a reality. There is no visible improvement. And the request for another process is not new at all. Neither is the offer to help. But everytime the answer was we are working on a new process (that was in 2003) http://qa.openoffice.org/servlets/ReadMsg?list=devmsgNo=1071 http://qa.openoffice.org/servlets/ReadMsg?list=devmsgNo=1117 If you don't participate, you shouldn't complain if it doesn't happen. And if you and others don't participate because you 'foresee' it not becoming a reality, then that may simply be a self-fulfilling prophecy. Just have a look how long it took to get back the old quickstarter (and the responsible owner of the spec still thinks he was right apparently) - just see the feedback of the incompatible change regarding line-breaks justified paragraphs. Just take the crippled mail-merge. But most important: Do a query for open RFEs. Pick 50 random issues. And all 50 of these will have reassigned to bh/ft/requirements or What is going one with this issue as last comment. And the problem is the participate. Currently, the only
Re: [native-lang] Update: Sun/NLC meeting
On Thu, May 05, 2005 at 12:51:34PM +0200, Robert Vojta wrote: Christian Lohmaier [EMAIL PROTECTED] writes: Hallo Christian, This sounds familiar to me.. It's duplicate of issue 21282 yes and no. Issues are about the same problems, but the #i21282# is for 1.1.x and #i35830# is for 1.9.x. No, the version-field only tells you when the issue has been discovered/reportet, not when it will be fixed. It doesn't make sense to have two issues for the same problem, with the same fix. Once the issue is fixed for one branch, you can clone the issue to integrate it into the other branch. Having two issues open that may lead to two different approaches to solve the issue is counter-productive. ciao Christian -- NP: Rage Against The Machine - Wake Up - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Malayalam Language project: Clarification needed
On Wed, Apr 27, 2005 at 11:02:44PM -0700, manu unni wrote: [snip] All your questions are more suited for the [EMAIL PROTECTED] list. That's where the OfficeSuite gets translated and localized. Native-Lang is for activities (marketing, user support, coordination, etc) in the corresponding language. ciao Christian -- NP: Sepultura - Nomad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Re:[native-lang] Re: [l10n-dev] N. Korean localization : Impossible?
On Sun, Apr 10, 2005 at 10:03:38PM -0700, Jonathon Blake wrote: Christian wrote: Do they sell/distribute their library? Do they provide documents using this encoding? Pretty much anybody can walk in and use their library. So what? This is not exporting in any way. And how does this relate to North Korea in special? For starters, they do have material from North Korea. OK, that should have read: relate to the embargo I've seen a couple of references to them converting material in KP 9566. ..but they do not offer a product that does this convertion, do they? They do share their resources with other libraries. You don't seem to get my point. (and worse: you don't semm to even try to get it). Again: Do they offer a product that converts the charset to unicode or another one? Sharing the results of such a conversion is a completely different thing. But you're unwilling to give reference to the post where you mentioned tho those lanugages/countries or to name them again? Message ID # [EMAIL PROTECTED] Again not very helpful. You cannot search for the MsgID in the archives. Even if you could, you still would not know where to serach (what list did this go to). I tried to search for it in gmane, but the relevant list apparently is not archived. The recent posting from you (using the email-address you use here) is dated Feb 10 b) I have not named the OOo NLP Team. And what has this to do with the topic again? Just the fact that they have contributed code that is in OOo. What fact, what contribution? Please explain what you mean with I have not named the OOo NLP Team and how this statement relates to this topic. I as well have contributed code that is in OOo - how does my contribution relate to this topic? - There is no relationship. Read my lips: Neither the korean language, nor any korean script/writing system was rejected. Did you even _read_ that issue? KP 9566-2003 _was_ rejected. It is a character encoding scheme. It is NOT a language. It is NOT a script. It is NOT a writing system. What was rejected is a feature that could be interpreted as an act in making a tailored version for the NK-market, So explain the features that could be interpreted as making a tailored version for other _counries_ on the embargo list, that are in OOo? GRR. Again: WHAT features? Come on, are you really serious about your style of discussion? Why don' you just mention concrete examples? Name the features and I will comment on them. And these text documents came from where? NK? From a national of NK? - Nope. They came from a us resident, who I assume is a US citizen. [no oriental heritage in their background.] I did not mean: who gave you the docs but who created them. But again: do you really think that this example can be taken as an argument in explaining that the addition of the feature is not related to NK in any way? And what do you want to tell with this again? How does fit into this discussion? How can this be taken as tailoring the product for an embargoed country? Same way that KP 9566-2003 can be. No, you don't get my point. Any further discussion doesn't make any sense since you don't even try to understand the point. If you mean Syric script - this clearly is a language thing and That is _one_ of them. You're comments are not helpful at all. Then name them! What is so hard about getting the facts into this discussion? You have facts, do you? (to me it seems you don't - you always give prevaricating answers) few exceptions that prove the rule). Do you even know what the expression the exceptions prove the rule means? I suggest not. For every rule there you can name an example that doesn't fit into the rule. This sigle example doesn't invalidate the rule, in contrary this enforces the rule (The fact that you can only give a handful of exceptions and not a truckload of exeptions). If you have another definition, than please post it. ciao Christian -- NP: 4Lyn - Feel Me - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Re:[native-lang] Re: [l10n-dev] N. Korean localization : Impossible?
On Mon, Apr 11, 2005 at 12:20:26PM -0700, Jonathon Blake wrote: Christian wrote: This sigle example doesn't invalidate the rule, in contrary this enforces the rule Thanks for demosntrating that you don't understand English. Thank you for demontrating that you're not interested in an actual discussion. What is wrong with my interpretation/what is the correct interpretation in your opinion? ciao Christian -- NP: Waltari - Follow Me Inside - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Re:[native-lang] Re: [l10n-dev] N. Korean localization : Impossible?
Hi *, On Sat, Apr 09, 2005 at 08:48:50PM -0500, Jeongkyu Kim wrote: charles-h.schulz wrote: First, OOo is not bound by US law. In fact, one wonders what law is applicable to us since we have no legal existence as a united body (sigh, sigh). Sun shares the copyright for every contribution that goes into the Source - if a patch is accepted, Sun is involved directly. But the fact that Collabnet and Sun take part in the process make the things more difficult since they're based in the US. So, OOo is not bound by US law but 'OOo process' is bound by US law, correct? Yes, this is my understanding (as a non-US citizen). [...] [...] You're right, who knows? So, should we find out? I could not find any other intention except introducting new language into OOo. One additional problem with the patch (issue 33466) is (from my understanding, from sb's comment) is that it is not a language thing, but a customization especially suited for people in NK (as this charset is not used anywhere else). This ist what it makes hard to explain that this addition is not intended to support NK (but it only a language). A feture that is only useful to people with (at least) relationship to NK/for NK itself. [...] I have come to think to another very frustrating solution but it would be still a bit better than the first one (separate hosting): name one of the KO native-lang project contributor/developper as the one who will upload the patches of IlYong. It will solve all the problems since it will be submitted by a SK citizen that could, in theory use the NL locale for his own pleasure and family use (like if he was nostalgic of living in Pyongyang). It if was only language, this will/would have worked. I seems everybody seems to get upset without knowing about the issue. It lasted till today until someone posted a link to the issue. Either there are more issues of everybody is talking about different things here. I don't believe it will work It appears to me that those patches were rejected not by his intention but by possible result of it (which Sun assume). Exactly my impression. It is hard to explain the US-Authorities that adding support for the N. Korean national standard charset is not supporting NK While for this reason this will not make it into the official sources, the community (or: the part of the community that is not bound to this stupid US-regulations) can create and distribute a modified version of OOo that includes support for this charset. This is more work, but at least this is possible at all (would be a lot harder (maybe impossible) when OOo would not be OpenSource) ciao Christian -- NP: nichts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] N. Korean localization : Impossible?
Hi Aiet, On Sun, Apr 10, 2005 at 01:50:18PM +0400, Aiet Kolkhi wrote: CL Sun shares the copyright for every contribution that goes into the CL Source - if a patch is accepted, Sun is involved directly. This is true. CL One additional problem with the patch (issue 33466) is (from my CL understanding, from sb's comment) is that it is not a language CL thing, but a customization especially suited for people in NK (as CL this charset is not used anywhere else). Like it was said at the beginning, the law targets country and not people. And there are indeed people from NK living abroad. No, it doesn't only touch the country. See this Eula refering to the regulations: http://www.csd.toshiba.com/cgi-bin/tais/eula.jsp , | Export Control Terms | | [..]NO SOFTWARE FROM THIS SERVER MAY BE DOWNLOADED OR OTHERWISE EXPORTED | OR RE-EXPORTED (A) INTO (OR TO A NATIONAL OR RESIDENT OF) CUBA, IRAQ, | LIBYA, SUDAN, NORTH KOREA, IRAN, SYRIA, OR ANY OTHER COUNTRY TO WHICH | THE UNITED STATES HAS EMBARGOED GOODS [...] ` So it touches everyone living in NK (resident of) and everyone whose nationality is NK (a national of) - no matter where they live. So it /IS/ about the people as well. CL This ist what it makes hard to explain that this addition is not CL intended to support NK (but it only a language). I think 'support' is a very general term here. With the same attitude, publishing a travel book or dictionary about NK and its language (be it language or dialect), can also be seen as supporting NK. The law forbids the _export_ of a product, which I don't see any reason has anything to do with adding support to a product. I don't know all the laws regarding this subject.,,, This explicit regulation refers to the export, but this doesn't mean that there arent other regulations that control the support itself. It if was only language, this will/would have worked. I seems everybody seems to get upset without knowing about the issue. It lasted till today until someone posted a link to the issue. I think Kim posted a link about the issue from the very beginning, which started all the discussion. That was to the l10n list probably. ciao Christian -- NP: nichts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Re:[native-lang] Re: [l10n-dev] N. Korean localization : Impossible?
On Sun, Apr 10, 2005 at 09:59:27AM -0700, Jonathon Blake wrote: Christian wrote: but a customization especially suited for people in NK (as this charset is not used anywhere else). Unicode 0x6F6E has a modified form from KP 9566-97. KP 10721-2000 maps to a Unicode sub-range. KP 9566-97 maps to a Unicode sub-range. ? Character-coverage has nothing to do with charsets/the encoding used. KP 9566-2003 was submitted to the Unicode Consortium as a replacement for KP 9566-97 mapping. BTW, CPAN has a module for the conversion of both KP 9566-97 and KP 10721-2000 to Unicode. So what? Doesn't make this charset more useful for people that have nothing to do with NK (and that is my point) only useful to people with relationship to NK/for NK itself. CF University of Washington: Seattle, WA. ? You have to give more information. Either there are more issues of everybody is talking about different things here. Maybe you will be able to explain why OOo has support for countries / languages / writing systems on the Country embargo list, then. If nobody names them I cannot comment on them. Again: It was not the korean language or the korean writing system that was rejected. What was rejected is a feature only useful to NK (or people having to do with NK). While this is not necessarily true 100%, the concern ist: Explain that to the US-Authorities At a minimum, Sun legal should be consistent in the patches that they accept/reject. At a minimum people should name facts, name the issues they're talking about. Before they start a big discussion. What other patches for languages/countries on the embargo list are you talking about? distribute a modified version of OOo that includes support for this charset. How about a python script that converts plain text to/from Unicode? Once in Unicode, it can be edited in OOo. That doesn't solve the problem of: a) writing to the character encoding. b) Reading non-plain text files that use that character encoding. A version of OOo that inlcudes the patch solves these problems. ciao Christian -- NP: Jimi Hendrix - Freedom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Re:[native-lang] Re: [l10n-dev] N. Korean localization : Impossible?
On Sun, Apr 10, 2005 at 02:15:37PM -0700, Jonathon Blake wrote: Christian wrote: Doesn't make this charset more useful for people that have nothing to do with NK (and that is my point) The KP 9566 character set was what Sun Legal rejected. Sure but you then argumented that Unicode covers the characters of that codepage. And this is irrelevant. only useful to people with relationship to NK/for NK itself. CF University of Washington: Seattle, WA. ? You have to give more information. It just happens to have the second or third largest Korean library in North America. Do they sell/distribute their library? Do they provide documents using this encoding? And how does this relate to North Korea in special? I've seen a couple of references to them converting material in KP 9566. ..but they do not offer a product that does this convertion, do they? Maybe you will be able to explain why OOo has support for countries / languages / writing systems on the Country embargo list, then. If nobody names them I cannot comment on them. a) I have named the other countries / languages / writing systems. But you're unwilling to give reference to the post where you mentioned tho those lanugages/countries or to name them again? A great basis for a discussion. b) I have not named the OOo NLP Team. And what has this to do with the topic again? Again: It was not the korean language or the korean writing system that was rejected. What is KP 9566-97 if not an encoding scheme for a version of the Korean Writing System, then? What is KP 9566-2003 if not an encoding scheme for a version of the Korean Writing System, then? Read my lips: Neither the korean language, nor any korean script/writing system was rejected. As you mentioned yourself: These character sets are covered within unicode. What was rejected is a feature that could be interpreted as an act in making a tailored version for the NK-market, because this character encodings have no significance outside NK/they always relate to NK in some way. What was rejected is a feature only useful to NK (or people having to do with NK). While this is not necessarily true 100%, the concern is: I wrote a python script to convert KP 9566-97 to Unicode. I didn't write it because it might help somebody in PDRK. I wrote it because I had a text document that used that encoding. And these text documents came from where? NK? From a national of NK? - here you go. What other patches for languages/countries on the embargo list are you talking about? Take a look at Issue # 34007, for one. And what do you want to tell with this again? How does fit into this discussion? How can this be taken as tailoring the product for an embargoed country? If you mean Syric script - this clearly is a language thing and furthermore no special addition to support Syric script, just to correctly mark the scripts as CTL (as many others). Syric language is used in far more countries than Syria - whereas the encoding (not language) this discussion is about is used exclusively in NK (with the few exceptions that prove the rule). A version of OOo that inlcudes the patch solves these problems. That requires a fork in OOo --- something I'm not opposed to, btw. I wouldn't call it a fork if it is only keeping a single patch in sync with the upcoming versions ciao Christian -- NP: Metallica - Helpless - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[native-lang] save as text (encoded) with japanese OOo; please test/confirm issue 36546
Hi *, message sent to both [EMAIL PROTECTED] as well as [EMAIL PROTECTED] When you're using the japanese version of OOo 1.1.3 (or can quickly install it for a test) - please check whether saving as text (encoded) gives the expected results. According to issue 36546 http://www.openoffice.org/issues/show_bug.cgi?id=36546 This did work properly in OOo 1.1.2, but with OOo1.1.3 it doesn't work anymore. From evaluating the issue, I suspect that there is an offset between the entry shown in the GUI and the one actually used. Please check whether you can reproduce the problem. Thank you. Ciao Christian -- NP: Paradise Lost - Yearn For Change - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Stylist vs Styles and Formating
Hi *, On Sat, Jan 22, 2005 at 12:37:21PM +0100, Charles-H. Schulz wrote: [...] In the particular case of the Styles and Formatting issue, it was more a problem because the way this change hasn't been commuicated to the community and approved/discussed by the community than a strong refusal to the name change. There are definitely some strong arguments against the name change, but the most critical part of all this story was the inherent failure to communicate from some people at Sun. I think you (esp. Daniel) are still missing an important point here: It is not the new english string that is the problem. The translation of the new string is the problem! Stylist - Styles and Formating is surely understandable, but Stylist - Formatvorlagen und Formatierung is bad. Not only because it is no longer called Stylist, but the whole naming is more than redundant. The menu is Format|Formatvorlagen und Formatierung! The same goes for Wizard this may be straightforward in english, but sucks when translated literally. ciao Christian -- NP: Paradise Lost - Once Solemn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [native-lang] Stylist vs Styles and Formating
Hi *, On Fri, Jan 21, 2005 at 01:08:14PM -0500, Daniel Carrera wrote: Christian Lohmaier wrote: Excellent. This means that the French project can call it Stylist and the English version can call it Styles and Formatting, right? No. Because localization for a couple of languages is done Sun-internal. I don't understand what you just said. If french or german or other any other language that is handled sun-internal native-lang-project wants to have a string changed, this has to be done (and therefore approved) by Sun. And sun internal may be misleading. AFAIK Sun pays for the translation for those languages (maybe its only the OnlineHelp that Sun pays for to be translated - don't know exaclty). This is also the reason why fixing typos for those languages can take ages. What makes the German project and Autopilot different from the French project and the Stylist ? German-lang project was involved in the naming-process for the AutoPilot. German language is special in another aspect: It is part of the main sources, not of the translation-files. English and German UI strings are set directly by developers (not translators). What the strings should look like is defined in the specs. ciao Christian -- NP: Downset - Prostitutionalized - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
