Re: [l10n-dev] NEW Locale Data Audit - please participate!
Hi Eike, Today at 18:39, Eike Rathke wrote: On Thu, Feb 09, 2006 at 14:27:03 +0100, Tomislav Randjic wrote: I will add EUR to the used currencies for *_CS, just that it opens the question which would be the default. CLDR lists EUR as default. Is that correct? Nope, CSD is correct, read below for some elaboration. For now, default for sr_CS should be CSD, and EUR should be there also to overcome current situation with Euro in Montenegro. Please allow me one question: is that a voice from Serbia, or a voice from Montenegro? You can count it as voice from people: at least 90% of population of Serbia and Montenegro lives in Serbia-proper (not counting Kosovo in, it's 8 million vs 0.8 million [and note that it's probably more than 8 million, and less than 0.8 million, so I am not being gentle on Serbia, but rather vice versa]). Generally, it's politically a very sensitive question, and you avoid most of the fuss by setting CSD as default currency (there's more: Kosovo with 1.2+M is nowadays probably using EUR as well, even if it's part of Serbia [or isn't, I am not going into political discussion here]). Note that also some day names would be spelled out differently in Montenegro (eg. for Wednesday: сриједа instead of среда, or in Latin transcription srijeda instead of sreda), so generally, sr_CS is a locale more suitable for Serbia part of the union. That's why I designed a [EMAIL PROTECTED] locale for GNU libc (which is usable in both Montenegro and Bosnia [in Serbian areas]), basically for Jekavian dialect as used in Balkans, yet it never garnered enough interest (the number of people that might use it is really small). Note that each dialect is as much Serbian as the other, so if we bring this into discussion, we'll never achieve anything: the voice from Serbia is going to be more useful to a MAJORITY of people, and that should be the only criteria. Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Serbian correction, sr_YU.xml sh_YU.xml
On December 2nd, A. Prusac wrote: And now we are asking Karl to implement something that exist only virtualy (out of font, out of keyboard layout). Not exactly. Unicode supports LJ, Lj, lj (note the three cases) digraphs (somewhere in the 0x1c? range if I remember correctly) for Croatian (or Serbian Latin), and Unicode Collation Algorithm (Unicode Technical Report 10) supports contractions and expansions (in their terminology, l j contracts into a single collating element lj). OOo supports all this I think, as well as does ICU, GNU libc, and many other libraries and systems. It's realy seems like a mission impossible task. Not really, and this is not only Serbian-specific (or Croatian, for that matter). It's also present in Czech, Spanish (or old spellings/collations in it), etc. Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Cyrillic alphabet numbering
Hi Yury, Yesterday at 11:24, Yury Tarasievich wrote: I've told you before, two-letters itemization isn't used in Eastern Slavonic languages, at least one won't be allowed to use that in the scientific article or in the official document. I am of opinion that this is a good enough generalization providing safe getaway when one itemizes a list with more than NUMBER-OF-LETTERS-IN-ALPHABET entries. Alphabetic numbering won't be used with big lists, but it's ok to have algorithmic fallback just in case it does happen: it won't hurt anyone who doesn't use it, it will look strange to those who happen to use it, so they'll switch over to other types of itemization. So, if you'd like others to re-use this, then there should be some means for customization, at least on the per-language basis. It's most commonly used in case of book appendices or book parts, other than short lists, and there are usually not too much of those. The other option is to simply NOT SUPPORT lists longer than the alphabet size, which is as good as the current solution (having list items lose their number past the last letter of alphabet is as unexpected as is аа or аб). At least IMHO :) FWIW, we have a bunch of l10n patches going into Yelp (Gnome DocBook docs viewer) these days, which do the same thing. Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] gettext again
Hi Eike, Today at 16:37, Eike Rathke wrote: Also OOo string resources already may have comment info: the language x-comment is reserved for adding comments to string resource entries. However, in first place it has to be used by the developers who add/modify the resource strings, and second be supported by tools that extract the strings and/or convert them to .po or other translation systems. I am really used to the level of support translators get in Gnome: when we have unclear message, we report it as a bug, and it either gets reworded, commented, or both, by module maintainer. It's nice to know that OOo already supports that in one way or another, of course. The big question is: how much effort would be needed to port OOo to use gettext? An even bigger question is: would gettext be able to handle it? How does it scale? Would it be worth the effort? It's used for Gnome (30+k translatable messages for the core, over 80k with a bunch of apps like Gimp, Gnumeric,...), KDE (I think it's around the same for the core, grows again to over 80k with apps), XFCE and many other applications and environments. FWIW, Gnumeric (5-6k messages) is a hell of a lot faster and responsive (personal feeling, not a real measure) than OO Calc on my celeron2.3ghz, 636mb ram system, so I can be positive that gettext is not going to be a bottleneck. And yeah, it also combines some translatable messages from other sources, such as Gtk+ stock items (menus and buttons), libgnomeprint dialogs and stuff, etc. I can also describe some of the implementation details, like MO files being mmap()-able, containing alphabetically sorted strings (allowing O(log N) search), but also having a hash table (allowing O(1) string matching, alas, this is undocumented implementation detail on GNU systems; I don't know about Solaris or other gettext implementations). Yes, in my opinion, it would be worth the effort. If it still applies, the first obstacle that always came to my mind with any gettext implementation: the original string is in the source code. If that needs to be changed you need to recompile and link. _And_ you have to change the string in the corresponding gettext resource. Yes, original strings are in the source code. But if you wish, you can treat them still as simply keys in cases where you don't want to change a string in the source code (such as string freeze periods): you can provide en_US translation or something like that to introduce typo fixes, etc. GNU gettext tools provide excellent programs to handle corresponding gettext resource (i.e. MO and PO files), so you get automatic fuzzy matching, translation reuse, and it's all done automatically without programmers caring too much. Also, I don't really see the value of this argument, since with current OOo system, AFAIU, both original and translated strings end up in the source code. Having only original ones there is clearly better, no? PO files and gettext performance allow us to set up statistics systems updated every couple of hours DIRECTLY FROM CVS/SVN such as: http://l10n-status.gnome.org/ http://i18n.kde.org/stats/gui/stable/index.php Why don't we get those for OOo? (these are one of the most valuable things translators have when working with PO files: it's not really about PO files, but about how simple it is to create such web pages working almost real-time: yeah, we are currently testing another version for Gnome where updates will happen on cvs commits instead!) Note that both of these are larger code bases than OOo, they are regenerated with simple fuzzy matching algorithm from GNU msgmerge [so it's not the fastest available method], and it takes two or three hours for complete Gnome pages to be regenerated for ~100 languages. In the past we already had quite some discussion about gettext and came to no conclusion where it was feasible to switch to gettext, did anything change in that system? Depending on what you consider feasible. I understand that there is some value to having all strings in resource files, but it inevitably leads to many problems for both programmers and translators (did it ever happen for a programmer to display a wrong string? or translator to match a wrong translation with it since original has been updated?) Of course, to be serious, I am definitely biased toward the format (I have my own implementations of MO file parsers for PHP, C#, even Perl for intltool), but only because I find it so natural as both a programmer and translator! Nowadays where tools like oo2po exist I wouldn't say that switching to a gettext based approach would be necessary from this view. However, there are some features of gettext that are worth taking a look at, like language dependant plurals, but much more important for lowering the barrier would it be to separate all localization effort from the source tree, and not having to run a build in the entire source tree just to (re)assemble some strings and
Re: [l10n-dev] Requesting Arabic builds
Today at 19:47, Pavel Janík wrote: can you please follow this exactly: Please send me the URL of your GSI file that is named GSI_cs.sdf.bz2 (bzip2 or gzip compressed GSI file where cs is the ISO code of your language). Several scripts and also people rely on this naming. Ok, I've put them up at: http://prevod.org/ftp/oo/GSI_sr-YU.sdf.bz2 http://prevod.org/ftp/oo/GSI_sh-YU.sdf.bz2 (explanations below) Hmm, what should I do with two GSI files? According to the table at http://l10n.openoffice.org/languages.html, Serbian Latin's ISO code is sh-YU, so your GSI file should be named GSI_sh-YU.sdf.bz2 Or is the problem in the table? Can you please send me updates to the table? Problem is deeper than that. We have discussed it earlier on this list. We need locale to be named [EMAIL PROTECTED] (or something like that: Latn is ISO15924 script identifier), but OOo locale system currently doesn't support script identifiers. Using sh (deprecated—i.e. unassigned—ISO 639 code for Serbo-Croatian) is just a hack. Also, YU has been replaced with CS code, but we are planning on fixing that only in future OOo releases. Also, our responsible person has changed, so I am not really sure how to send updates to the table (I don't have access yet to sr.openoffice.org which should be our team's page, etc.). This should not be hard to solve, I just lack the time to do it all right now. Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Requesting Arabic builds
Yesterday at 21:12, Pavel Janík wrote: Now, since Serbian is integrated now, do you want me to send you a link to GSI file, or what do I need to do so you can add Serbian to the list as well? ;-) you should read my blog again. Ok, ok :) http://prevod.org/ftp/oo/sr_CS.sdf.bz2 — Serbian http://prevod.org/ftp/oo/[EMAIL PROTECTED] — Serbian Latin Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] TABLE: Serbian introduced in 2.0
Hi Pavel, Current Serbian web site is at http://sr.openoffice.org/, and Branko Tanović [EMAIL PROTECTED] is currently in charge of it (and as he told me, his SSH key is no longer working so he can't update the page). However, the Serbian Gnome translation team (http://prevod.org/) has organised and completed Serbian translation of OOo UI (except for the helpcontent), and it has recently been integrated into OOo 2.0 (you've even verified it in a bug report :). Branko has authorised me to coordinate all this, and I'd like to be able to edit the page as well, and to have it listed there, and I should probably be listed as a responsible person as well. As soon as Branko gets enough time to work on this again, I'll probably pass the batton back to him ;-) My account name on OOo is dsegan, if that's important. If there is anything else needed to be done apart from having the table updated, I'll do it later (I didn't yet check all the relevant docs pages, I lack the time right now, but I wanted to respond to your keep table up-to-date query). Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] hello there
Today at 3:55, Javier SOLA wrote: I am not sure of this, but Pavel or David will know. Is it possible to default to French? or convert from PO to GSI including French as back-up language? You can use French PO files as compendiums (-C option to msgmerge) along with your PO files and Pavel's OOo POT files. FWIW, I think it's even wiser to keep your own half-translated PO files and merge them with French only prior to install step, so you know how many (un)translated messages you actually have. Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOoCon presentation: i18n for l10n
Hi Eike, Today at 15:28, Eike Rathke wrote: I'd be interested in more stuff such as multilingual spell-checking support, Hum? What do you mean by multilingual there? Eg. combined English and Serbian (since they use different scripts, i.e. Latin and Cyrillic, one can automatically choose between the two and use proper dictionary). support for different date/time formats [read: genitive for Slavic languages] etc. This is already on my list. Great! I hope you'll be providing us with slides and maybe even a video of your talk :) Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Adding Serbian l10n
Hi Ivo, On July 25th, Ivo Hinkelmann wrote: Send your email ( take care of the size! ) to Eric.Renaud at Sun.COM, but you have to send the original document by snail-mail due legal issues. I didn't receive any response from Eric. In July I e-mailed all the scans of signed documents which I also sent by snail-mail (but I don't expect them to arrive before tommorow). Will it be possible to include Serbian translations (I can resend the documents, but it may be due to big sizes or whatever, and I can let you take a look at it) even if I didn't get confirmation from Eric? Should I try fax instead (I mean, will that allow it to be processed faster)? It's really important to us to have this included now (we basically set out to finish this in time only a month ago, losing much of our otherwise spare time, so having it included would be a big satisfaction booster :). - submit SDF file to you (I've put current, m121-based version at http://prevod.org/ftp/oo/sr-CS.sdf.bz2) File a issue to me ( 'ihi' ) We're looking our translation over one last time, and I'll submit a complete (or at least 99%) translation tommorow. Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Adding Serbian l10n
Today at 20:54, Ivo Hinkelmann wrote: you don't send him 5 * 10 MByte ? Usually there are size checking filters in the mailserver. No, the total turned out to be around 2MB when base64 encoded (base64 increases size for 1/3 or 33%). you take a look at it) even if I didn't get confirmation from Eric? Should I try fax instead (I mean, will that allow it to be processed faster)? I hope you already send the snail mail letter to him ? If he received your scans and 2 or 3 weeks later your snail mail arrives, then it is ok. Ok. Lets hope for the fast post service. :) It's really important to us to have this included now (we basically set out to finish this in time only a month ago, losing much of our otherwise spare time, so having it included would be a big satisfaction booster :). I am optimistic that I can integrate your translation! Great to hear that. Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] sr-CS/sr-YU locale data
Hi Eike, Yesterday at 19:35, Eike Rathke wrote: I can make something up (and using am/pm or ??/?? is just making it up), but what reasons would I use to justify that? You would be able to distinguish am/pm if loading a foreign document that uses system locale and has 12 hour format set. You misunderstood me: I perfectly understand the reason behind having them. I need justification for choosing any one mechanism over the other. Because I'd get quite a few questions asking why didn't you use this instead? if I'd make a choice without good arguments. I mean, should I organise voting and recommend several variants? I don't really think voting is a good choice-maker here, but it's kind of objective (you can say: YOU voted it, it's not my choice). Same in Germany (btw, the new CLDR defines time ranges for such constructs). Nobody would say 4 before noon if talking of 4 o'clock in the morning, nor 8 after noon if talking about 20:00 in the evening. Still we have defined before noon and after noon. As long as the format isn't used in a document you don't care, do you? And it it was used, there would be some reason for it. I agree. But making something up is going to confuse users. I can use am/pm knowing that most educated people will know what it means (since they're likely to be familiar with basics of English language). But note that this is only most of the educated people, which are still a minority. (Of course, I didn't do any actual study, so I may be entirely wrong.) Perhaps using am/pm is best, since it's understandable for at least a part of targetted population. I'm trying to come up with the best solution, and I don't have the resources to do a study or ask goverment standardisation institutions to define standard 12-hour format. What did you actually put for German, and what was the reason and justification? In my opinion, if twelve hour format is used, it should be without any specifiers for Serbian language, even though it would be ambigous. Well, that's your opinion. What do others say? I don't know. There is no standard, and whenever someone talks about date and time formats, they insist that 24-hour format is what we use. Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] sr-CS/sr-YU locale data
Yesterday at 15:29, Eike Rathke wrote: Also, sr-YU should be renamed to sr-CS, since country code for Serbia and Montenegro has changed to CS from YU along with the name change from Yugoslavia in February 2003 (code change has been done in ISO 3166 in July 2003). Which was rather short-sighted to put it mildly, as CS before was used for Czechoslovakia. Reusing the code was a very bad idea. We had a discussion about that in 2003/2004, see my mail http://l10n.openoffice.org/servlets/ReadMsg?list=devmsgNo=2976 and the thread it appears in; for those with a local mail archive, it's Message-Id: [EMAIL PROTECTED] How come nobody noticed such short-sightedness (I agree it sucks, but look at how ISO 3166 was defined ages ago) when similar happened in 1991: country of Bosnia and Herzegovina, Croatia, Macedonia, Montenegro, Serbia, Slovenia used the code YU, and then that code was assigned to country of Serbia and Montenegro. Technically speaking, this change was very similar: applications which misused YU to refer to pre-1991 Yugoslavia would either mistake old data (eg. Croatian) to be Serbia and Montenegro only, or would mistake new data to be former Yugoslavia data (eg. it might be relevant to Slovenia). So, all data applications unable to cope with this change (i.e. differentiating between pre-1991 YU and 1991-2003 YU) were broken in meaning and sense, and they're only ones affected by this change. All applications now need to cope with another such change, and it's even simpler in practice, since the timeframe between the change is some 12 years (pre-1990 CS and 2003-now CS). Of course, nobody bothered with the former change, because nobody seemed to care, but suddenly it's important for those data applications? It's all hipocrisy to me. For those that don't know, ISO 3166 has *FOREVER* been defined as the following: - two letter country code resembling country name - may be changed in accordance with the country name change - may be reused Now, everybody's broken applications which didn't follow the specs are ISO 3166's fault? Citing from that mail: | As there is no real solution to this problem, and still no decision made | by any authority, especially not the ISO 3166 maintenance agency, we'll | stick to YU for the following reasons: | | - Almost all already existing software only knows about YU, not CS. Not | using YU in the file format would result in unrecognized locales in | interoperability. This has changed. GNU libc in 2.3 and HEAD branches knows only about sr_CS, and not about sr_YU. | - ICU, the i18n library OOo uses, has YU entries, using CS instead would | only lead to error prone mappings at all times. In a list of countries (as translated in each ICU locale), I see CS for Serbia and Montenegro. There is no YU: http://www-950.ibm.com/software/globalization/icu/demo/locales/en/?_=srSHOWCountries=1#Countries Region is not otherwise specified for sr in ICU. CLDR also uses CS already: http://www.unicode.org/cldr/data/diff/main/sr_CS.html | - WIPO recommends the use of YU until the ISO 3166/MA has taken a final | decision, see | http://www.wipo.org/scit/en/meeting/sdwg/4/pdf/scit_sdwg_4_6.pdf | section 5. I don't understand why everybody thinks nobody knew about the problems in ISO 3166 commitee? It's been two years since a change. It took 5 months to finally agree on a code change from YU to CS (as I said, country name was changed in early February 2003, ISO 3166 changed code only in late July 2003), after *several* meetings without a decision. In my eyes, I see this only as an indication that it was hard to come up with ANY solution, and that CS was the best solution possible. Complaint was sent right away, but it's been two years without a resolution, so I don't see anything changing here. CS is now already widely used. For instance, bank SWIFT codes (used in electronic money transfers) all use CS. The same is everywhere else (currency code is now CSD). Not to mention that I can't see WIPO as relevant here. Anything using term intellectual property (I can understand term intellectual creation, but as soon as I publish and/or make available a certain intellectual creation, there is no way to insist that it's still my own intellectual property [property of my intellect/mind], since others will be able to understand it, intellectually process and recreate it) is not the source I'm going to trust. I should probably pull out a random multinational organisation (uhm, how about ISO?) which recommends using CS over YU. Oh yeah, it's a sensitive topic, but lets not put out statements from someone we agree with as look, they agree with me as well as any more objective than others. Or, what is current situation in OOo: lets wait until they change a decision to make it align with my own opinion. As I said, the problem is that everybody was expecting to use ISO 3166 in a different way than it was defined. And there is
Re: [l10n-dev] sr-CS/sr-YU locale data
Yesterday at 15:30, Eike Rathke wrote: What about ICU? Will it follow? It already does (it seems since two weeks ago): http://dev.icu-project.org/cgi-bin/viewcvs.cgi/*checkout*/icu/source/data/locales/ Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] sr-CS/sr-YU locale data
As listed on http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html, starting with issue number 1188 up to 1227, CLDR is correct. As for issues 1186 and 1187 (am/pm identifiers), they are not used in Serbia and Montenegro at all. Also, sr-YU should be renamed to sr-CS, since country code for Serbia and Montenegro has changed to CS from YU along with the name change from Yugoslavia in February 2003 (code change has been done in ISO 3166 in July 2003). Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Adding Serbian l10n
Today at 20:30, Ivo Hinkelmann wrote: officecfg is important since nearly all UI elements except dialogs come from that module. Indeed. Just today we've reached 96.3% of it as well, so no need to worry about that one. :) Great ! We have not yet received any Serbian translation for the OOo 2.0 release, you are welcome! Excellent. I'm really happy to finally have OOo 2 in Serbian. We also have a guy working on spell checking for both aspell and MySpell, so we'll be looking into some help with that too :) Send your email ( take care of the size! ) to Eric.Renaud at Sun.COM, but you have to send the original document by snail-mail due legal issues. Ok, thanks, I'll do that. File a issue to me ( 'ihi' ) Ok, as soon as we have proof-read the translation (I want us to go through it all again), I'll file the issue and assign it to you. Please file issues for all language dependend patches. You can find a lot of information regarding this in Javiers Documentation at http://www.khmeros.info/tools/ Yeah, I've already found it. Thanks for pointing it out though! Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] Adding Serbian l10n (was Re: [l10n-dev] Another sdf collection round for the OOo 2.0 release)
Hi Ivo, I want to discuss inclusion of Serbian translation of OpenOffice.org 2.0. We're doing it using PO files, and I'm creating SDF file for my translators. We're already at 90% of the UI translation with only officecfg and instsetoo_native unfinished (not counting helpcontent, which we haven't tackled just yet). We'll certainly have this complete by August 5th. We here is mostly Serbian Gnome translation team (I'm the coordinator), with one member (co-coordinator) of Serbian KDE translation team (both Gnome and KDE have complete Serbian translations for two years now). I have experience with all l10n and i18n stuff, having done sr_CS locales for GNU libc, sr keyboard layouts for X11, worked on fonts such as DejaVu, gsfonts/urwcyr, FreeFont and done a lot of translations. I have talked to Branko Tanovic (sr.openoffice.org maintainer and team leader: [EMAIL PROTECTED]) on the phone, and he's agreed that we can take over the translation since he's currently overwhelmed with work and can't dedicate much time to this. If I understood correctly, I need to take the following steps: - get all (five or six of them) translators to sign http://www.openoffice.org/licenses/jca.pdf and fax and snail-mail this to you: can I send scans over e-mail instead of faxing (it would be much cheaper for me)? - submit SDF file to you (I've put current, m121-based version at http://prevod.org/ftp/oo/sr-CS.sdf.bz2) - look over anything else there is (locales, font defaults,...) Cheers, Danilo Last Friday at 15:29, Ivo Hinkelmann wrote: The OOo 2.0 release is coming closer and there are new or changed strings in the source code since the last l10n collection, what was arround milestone m104 . Those new / changed strings force us to collect another time, but this is also a chance for you to submit latest corrections and updates. The deadline for providing GSI / SDF files is 2005/08/05 Please update to milestone m121, because that milestone contains a new readme section. As handling full gsi files will cause work and consume a lot of time, it would be perfect if you can provide me with a difference between your previous submissing and your current sdf file ,so the provided file is a smaller. I don't mean a patch, but a file only containing new / updated strings. If this don't work for you, because you provided me with a ftp link to a constantly updated file or you are unfamiliar with unix tools and don't know how to create such a file, just provide me with your full sdf file. No problem. And as usual please: - File an issuezilla bug to me ( [EMAIL PROTECTED] ). Please don't attach your file directly to that issue, better provide a URL / link pointing to your file. Only attach if you don't have any webspace available. ( http://qa.openoffice.org/issue_handling/project_issues.html ) - Please take care that the GSI / SDF file format is not violated ( format errors like wrong amount of tabs, shifted columns, ... ). You can use the tool gsicheck to perform basic checks on your file. gsicheck is located in the transex3 module. usage: gsicheck -c -l myfile.sdf - We try to correctly update our database status information which would later help to improve the overall quality of the translation. If possible please provide a GSI / SDF file containing both, your language and the corresponding en-US source string. This is only nice to have and not (yet) required ! Please note that the en-US string have to be the same milestone like your translation. Cheers, Ivo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
