[l10n-dev] Re: IMPORTANT: OpenOffice.org 3.4 - Localization Schedule
Thank you! On 03/30/2011 11:54 AM, Frank Mau wrote: SDF-file for DEV300 and other are available e.g. on http://ftp.sh.cvut.cz/MIRRORS/OpenOffice/extended/ooomisc/sdf/ ... -- - To unsubscribe send email to dev-unsubscr...@l10n.openoffice.org For additional commands send email to sy...@l10n.openoffice.org with Subject: help
[l10n-dev] Re: IMPORTANT: OpenOffice.org 3.4 - Localization Schedule
Hi all, Does anybody know where the fresh POT packs for 3.4 (specifically, m103) might be found? Eventually, equivalent SDF will do. Thanks -Yury On 03/28/2011 02:50 PM, Yury Tarasievich wrote: Right, I know. However, there're no updates on Pavel's site after m98 or so. I thought the production might have been transferred or something. -Yury On 03/28/2011 02:22 PM, Ivo Hinkelmann wrote: we don't produce any POT's here, maybe ask Pavel Janik?!? ... -- - To unsubscribe send email to dev-unsubscr...@l10n.openoffice.org For additional commands send email to sy...@l10n.openoffice.org with Subject: help
[l10n-dev] Re: IMPORTANT: OpenOffice.org 3.4 - Localization Schedule
Right, I know. However, there're no updates on Pavel's site after m98 or so. I thought the production might have been transferred or something. -Yury On 03/28/2011 02:22 PM, Ivo Hinkelmann wrote: we don't produce any POT's here, maybe ask Pavel Janik?!? ... -- - To unsubscribe send email to dev-unsubscr...@l10n.openoffice.org For additional commands send email to sy...@l10n.openoffice.org with Subject: help
[l10n-dev] Re: IMPORTANT: OpenOffice.org 3.4 - Localization Schedule
Thanks!! And about the POT pack?.. -Yury On 03/28/2011 01:45 PM, Ivo Hinkelmann wrote: currently there is no fresh keyid build, but I can make one. I will try to do this week. -- - To unsubscribe send email to dev-unsubscr...@l10n.openoffice.org For additional commands send email to sy...@l10n.openoffice.org with Subject: help
[l10n-dev] Re: IMPORTANT: OpenOffice.org 3.4 - Localization Schedule
Could you point to the actual URLfor the m103 POT pack? Are there any KID builds with milestone numbers close to m103? Thanks On 03/25/2011 05:46 PM, RAFAELLA BRACONI wrote: Dear Translators/Localizers, as always in the last years, I've created a wiki page that gathers information on volume and deadlines for both translation and l10n testing for the next version of OpenOffice.org. http://wiki.services.openoffice.org/wiki/Translation_for_3.4 Final delivery deadline to upload translated files is April 27th. With milestone 103 all major UI and Help changes in the translatable ... -- - To unsubscribe send email to dev-unsubscr...@l10n.openoffice.org For additional commands send email to sy...@l10n.openoffice.org with Subject: help
[l10n-dev] re-submission needed?
Is there a need to re-submit an issue, if there were no major changes made to the preliminary 3.3.0 translation? -Yury - To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
Re: [l10n-dev] OOO330 l10n second update: status of l10n integration and CWS availability
On 08/28/2010 08:35 PM, Dick Groskamp wrote: Op 28-8-2010 16:51, Yury Tarasievich schreef: Does one install the 'kid build' alongside the 'plain' national build and then run either 'plain' binaries or 'kid' binaries? Yes, you do Or does one replace the plain build with the kid? Absolutely not ! In fact the KID is a kind of map to easily find parts of the userinterface or the help-files which are identified bij strings So every string you see in your normal installation will have a string attached to it ( yes that doesn't look pretty) Well, actually, I've made such builds before, from source, with bogus langcode and strings combined from translation and sdf row number prepended. This kid build just auto-prepending some id is a superiour solution, of course. Thanks! -Yury - To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
Re: [l10n-dev] OOO330 l10n second update: status of l10n integration and CWS availability
On 08/26/2010 03:58 PM, Rafaella Braconi wrote: ... Sorry to bother with this question, but, what are the kid builds used for? I've seen on the SDF a kind of ID prepended to each string, but can't figure out for what it is useful. In the keyid build each strings has a unique ID. If you find an erroneous string, you can search for the KeyID in the sdf file to identify the string that needs to be corrected. In this way you are 100% sure to correct the right string. The idea is clear, but how does one actually go about using the kid build? Does one install the 'kid build' alongside the 'plain' national build and then run either 'plain' binaries or 'kid' binaries? Or does one replace the plain build with the kid? Of course, I *could* find this out for myself, but I really need no complications with my OOO installation these days and so would really appreciate knowing in advance. -Yury - To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
Re: [l10n-dev] Typing Cyrillic in the exported PDF form fails
Well, AFAICT everything works here; either Cyrillics or West European diacriticals may be entered in the text input field (I didn't do anything with the input, however). Of course, I might be doing something slightly different of what you want to do. For the record, I created a doc and put a text input area and a pushbutton in it. I exported this to a PDF with 'forms in FDF format' and with no checks on 'PDF/A-1a' and 'tagged PDF' whatever those mean. I tested the exported PDF in Acrobat Reader 9.1.0. OS is Linux. -Yury On 03/30/2010 05:13 PM, Goran Rakic wrote: У уто, 30. 03 2010. у 15:34 +0200, Yury Tarasievich пише: You could be a little more specific on how to reproduce. What goes into OOO document, what settings are active for PDF export etc. Open OpenOffice.org and create a form with text input control. Export document to PDF with PDF forms enabled. Open PDF form in some PDF viewer with PDF forms support and try to type Cyrillic or other non-ascii characters in the field. - To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
Re: [l10n-dev] Typing Cyrillic in the exported PDF form fails
You could be a little more specific on how to reproduce. What goes into OOO document, what settings are active for PDF export etc. On 03/30/2010 01:37 PM, Goran Rakic wrote: ... I reproduced it using both 3.2.0 and 3.0 stable releases, with Serbian Cyrillic localization. Can other teams confirm are other locales affected as well? - To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
Re: [l10n-dev] OOo 3.2.1 l10n schedule?
Would you guys kindly remind, what's the milestone for the SDF/POT for this release? On 03/17/2010 07:39 PM, Ivo Hinkelmann wrote: Rafaella is currently on vacation but will be back next week. She might give a statement about this. André Schnabel wrote: the wiki mentions a l10n handover and translation delivery for OOo 3.2.1: http://wiki.services.openoffice.org/wiki/OOoRelease321 ... - To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
[l10n-dev] Re: bibliography entry styles?
Yury Tarasievich wrote: Is there an option for using (adding) the native styles of format of the bibliography entries? ... Well, I've found it (by chance, really). The settings for the parentheses' styles used *in document* are to be found in the *Index/table properties*. Of all the places. Also, choosing "numbered entries" in those properties hides the shortnames in index, too. Utterly unintuitive. -Yury - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] bibliography entry styles?
Is there an option for using (adding) the native styles of format of the bibliography entries? Currently there is (or seems to be?) only the [] form. E.g., in the Belarusian academical philology the () form is widely used. -Yury - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] How can I change the font size of the GUI?
Nguyen Vu Hung wrote:
Hello,
On Wed, Oct 15, 2008 at 11:57 AM, yanmin <[EMAIL PROTECTED]> wrote:
Hi,
When I make Tibetan localization, the Tibetan text appearing in the menu and
dialog box is too small to read. How can I set or control the font size of
the GUI?
Can you attach a screenshot?
It does also happen in Vietnamese OpenOffice.org[2]
To fix the problem, you can submit a ticket[1], wait until the dev
team fixes it,
or you can submit a patch :D
Currently the UI font gets chosen on the basis of fontconfig matching,
and all the usual tricks and options for setting it explicitly ("use
system font", "font substitution") are ignored. If one has an
unfortunate set of fonts on one's system, one's UI gets somewhat screwed.
-Yury
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] New l10n cws localisation31
Ivo Hinkelmann - Sun Germany - wrote: ... And the missing be-BY build is provided! Right, thanks! -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] pot files for dev300_m6
On Sun, 06 Apr 2008 20:15:37 +0300, Ain Vagula <[EMAIL PROTECTED]> wrote: > http://ftp.linux.cz/pub/localization/OpenOffice.org/devel/POT/OpenOffice.org-DEV300_m6-POT.tar.gz > > About dozen changed strings in dbaccess, framework, officecfg, sd, svx. How should the GSI files be named, for the milestones building processes to pick? I dug a little in the build script of Pavel Janik and didn't understand — it uses the same names both for the 2.* and 3.* series? --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] U+2026
On Tue, 11 Mar 2008 17:36:35 +0200, Eike Rathke <[EMAIL PROTECTED]> wrote: > On Tuesday, 2008-03-11 17:42:02 +0300, Rail Aliev wrote: ... >> What do you think about using '…' character (U+2026) instead of 3 periods? > > Would probably look much nicer (btw, that character is called > "horizontal ellipsis"), but is it included in every font possibly used > for UI? Speaking of which — am I the only one in whose OOO installation the substitution of the UI font (those "Andale UI" trick) doesn't work at all? I've filed the #84950 on it 2+ months ago, and the matter, as far as I understand, could be linked with some internal algorithm determining the font's "appropriateness". --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] PO and TMX contents do not match, help !
On Wed, 26 Dec 2007 10:20:36 +0200, Alessandro Cattelan <[EMAIL PROTECTED]> wrote: > Yury Tarasievich ha scritto: ... >> Maybe *I'm* not making myself intelligible? I'm talking about having things >> assigned to the strings like a "term variant", "type of use >> (menu/option/...)", "keep short" etc. Currently such info often has to be >> deduced from string ID, or lucky probe in the UI, even from sources digging. > I'm sorry, but I don't think I understand what your point is here. The > same meta-information could easily be included in an XLIFF file. "Could" being the operative word here. See, I don't understand where do you expect this info to actually come *from*. Somebody has to type in those thousands of meta-descriptors into the carrier file, after all. It might as easily be done with the extended SDF/FDS/whatever as with XLIFF, but resources ought to be dedicated beforehand. And so, in the case of hypothetical format switch resources ought to be dedicated "twice". That's why I strongly doubt the format switch at this juncture would facilitate the filling of the meta-info slots. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] PO and TMX contents do not match, help !
On Wed, 26 Dec 2007 09:56:57 +0200, Alessandro Cattelan <[EMAIL PROTECTED]> wrote: ... > translators, really need is a method to translate effectively using TM > and glossaries just like we do in the professional world. OmegaT would > have it all: a glossary extracted from SunGloss can easily be converted > for the tool and the OmegaT TM engine works very well... but then, > obviously, we need a TM that matches the content to be translated. Maybe I'm missing something, but how can the Sun's glossary/TMX or whatever be helpful without meta-information? No amount of toolchain change is going to address this by itself. Maybe *I'm* not making myself intelligible? I'm talking about having things assigned to the strings like a "term variant", "type of use (menu/option/...)", "keep short" etc. Currently such info often has to be deduced from string ID, or lucky probe in the UI, even from sources digging. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On Mon, 24 Dec 2007 15:53:42 +0200, Jean-Christophe Helary <[EMAIL PROTECTED]> wrote: ... > oo2po has failed to produce files that match the TMX data that SUN is > providing the community with and even though PO based translations > keep coming, using the current PO process _does not contribute to make > the translation workflow easier_. But obviously, for communities that > only know the current PO hacks such an assertion does not mean > anything... Right you are. Propose and implement what you wish, you still omit people in translating communities needing to re-learn etc. Take me for example — I get quite a fair re-use ratio with Kbabel, I don't feel comfortable with the "feel" of any free XLIFF-capable tools, and I have yet to see some good demonstration of translation-workflow-related advantages of the "new way to go". What I saw in my experience with OmegaT wasn't "better", it was "better some, worse some". Can't recall — did I say I'm opting out of this discussion already? --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On Mon, 24 Dec 2007 15:27:45 +0200, Javier SOLA <[EMAIL PROTECTED]> wrote: > We are working on new SDF->XLIFF, XLIFF->SDF and XLIFFUPGRADE filters > that we hope to finish soon. The filters will be integrated in the > upcoming version 0.5 of the WordForge off-line localization editor. Nice to know that! And are there any ideas on how to share meta-info between the translators, possibly? --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On Mon, 24 Dec 2007 11:29:59 +0200, Jean-Christophe Helary <[EMAIL PROTECTED]> wrote: > On 24 déc. 07, at 17:09, Yury Tarasievich wrote: > >> On Mon, 24 Dec 2007 00:52:45 +0200, Jean-Christophe Helary <[EMAIL PROTECTED] >> > wrote: >>> On 23 déc. 07, at 19:21, Yury Tarasievich wrote: >>> >>>> However, I do care about lack of meta-information which renders many >>>> actual translation issues hard to resolve. Your scheme does not >>>> address that matter and actually would postpone its resolvement. >>> >>> No, it does not. >>> >>> XLIFF is equivalent to SDF in terms of the possible availability of >>> "context information". >> ... >> Etc. etc. Wouldn't it be nice if all things were nice. Aren't you >> deliberately ignoring such factors as the workflow and manpower? > > This is specifically what I am trying to address. > > Why has SUN moved from a workflow that ensures the most efficient use > of previous translations to a workflow that does not ? Because it's not their priority? Because at the time this seemed (or actually was) the best available solution? Because the world-wide populariry of the "OOO translating" caught them unaware? > How hard would it be to have a few Java programmers improve the > current OLT filters so that SDF is supported there ? The OLT itself seems to be sort of "put on ice", as it seems. Or so I gathered in Spring, when accessing the possibity to XLIFF-migrate the OOO translation I'm taking care of. > How hard would it be to give translators access to the full source of > the help files for context ? > > Ie, what can be done in practical terms, besides for PO hacks, to > improve the translators' work and the output quality ? I.e., to add meta-information, be it Nth extra field of SDF or whatever carrier format, which would be an enterprise all by itself. The PO hacks, ugly as they are, work, and translations are coming in. The "new way to go", pretty as it may seem in theory, has yet to be implemented *and* to prove itself. What about *other* translating teams, after all? --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On Mon, 24 Dec 2007 00:52:45 +0200, Jean-Christophe Helary <[EMAIL PROTECTED]> wrote: > On 23 déc. 07, at 19:21, Yury Tarasievich wrote: > >> However, I do care about lack of meta-information which renders many >> actual translation issues hard to resolve. Your scheme does not >> address that matter and actually would postpone its resolvement. > > No, it does not. > > XLIFF is equivalent to SDF in terms of the possible availability of > "context information". ... Etc. etc. Wouldn't it be nice if all things were nice. Aren't you deliberately ignoring such factors as the workflow and manpower? I'll be opting out of this discussion now, I guess. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On Sun, 23 Dec 2007 11:55:31 +0200, Jean-Christophe Helary <[EMAIL PROTECTED]> wrote: > Yuri, I don't want to sound rude but you have it all wrong. I don't > care about the SDF format. Well, *I* don't care about modifications to the current (oo2po) process. However, I do care about lack of meta-information which renders many actual translation issues hard to resolve. Your scheme does not address that matter and actually would postpone its resolvement. As I see it, it's not quite possible to "choose" XLIFF 1.0 or 1.1, because some tools do 1.1 only (xliff<->po toolkit) and free visual environments don't do 1.1 (Sun OLT - yet? Python XLIFF editor). Cheers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On Sun, 23 Dec 2007 05:59:05 +0200, Jean-Christophe Helary <[EMAIL PROTECTED]> wrote: > On 23 déc. 07, at 01:53, Pavel Janík wrote: > >> Charles: what should be used instead of SDF? Do you have at least an >> idea? Will you help to implement it? ... > The answer is easy: > > XLIFF files directly generated from the XML for the help files and > from the rest for the UI. > > That is equivalent to a source->po process, and that is the way to go. Here I should point out that preciously little tools work currently with the 1.1 XLIFF (even Sun's OLT didn't process 1.1 in Spring 2007). Anyway, such change, while disruptive to many, would also be at least useless, if with it won't come extended meta-information coverage (string context etc.) So, possibly the real answer is "extend coverage of meta-information, extending the SDF format appropriately". --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On Sat, 22 Dec 2007 17:48:25 +0200, Jean-Christophe Helary <[EMAIL PROTECTED]> wrote: > I am mostly interested in translation workflows. The reason is that > whatever smart devices programers have considered for the code and the > UI, the localization proper will have to be done by translators. > > And there is not much brain storming on that side of the fence as far > as I'm seeing. And that is specifically what most of those l10n > discussions carefully avoid :) > > Btw, have you seen my post related to "easier" handling of .sdf files ? I'd say what "we, translators" could really do with, *right now*, would be more extensive meta-information in the whatever carrier format is used. Just my 2 cents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] details on translation update issue
Could somebody remind the details needed for the translation update issue, please? Those "Module", "Assign to whom" etc., which tend to get forgotten from release to release. :) Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Updates to l10n.openoffice.org/languages.html
On 30/08/2007, Robert Ludvik <[EMAIL PROTECTED]> wrote: ... > BTW, MediaWiki filter (odt2mediawiki in File - Export) works nice. It > only missed table border. Bit of off-topic, what's this odt2mediawiki extension? Where's it located (can't find it)? I made (adapted uniwakka's filter, really) something of the sort, rather crude, some time ago, but never was able to learn enough to produce results from the cells vertically-merged or from the footnote labels, to produce short refs of for the repeateds. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] POT files for OOo 1.1.5
On 04/02/07, Stephen Holt <[EMAIL PROTECTED]> wrote: Hi, and thanks for this, but unfortunately I had already looked at this site and the files don't go back as far as version 1.1.5. Or did I miss them? Any other advice on how to localize OOo 1.1.5 gratefully received. The only real problem would be the compilation of the ooo of 1.1.* series itself. It's bit convoluted and takes a lot of disk space and time. The adding of the localisation itself isn't that hard. And I believe you could retro-fit good deal of the 2.* strings into 1.* language file, so no redundant work there. Also, it's quite likely you'd have to settle for the "unknown/non-standard" status of your language, as nobody seems willing to expand those fancy numeric language codes in the sources for about two years already. Look for the 1.* compilation instructions on the openoffice.org site. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Translation Schedule for 2.2 - new UI strings in numpages.src
On 18/01/07, Pavel Janík <[EMAIL PROTECTED]> wrote: ... BTW - today is the deadline for GSI submission! So, the deadline is inclusive, not exclusive, and one may submit amended files today yet?
Re: [l10n-dev] Public Review of XLIFF v1.2 - 15 day review
On 08/01/07, Eike Rathke <[EMAIL PROTECTED]> wrote: I don't know if XLIFF could serve us in the translation process. It might be interesting in the long run for localization data exchange. ... Main problem here is that even XLIFF 1.1 isn't supported yet by any major (open-source) CAT tool. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Removal of German entries from the resource files
Unexpectedly, perhaps, the German strings have quite valuable hints *beyond* the content given by the English strings. Of use mainly to the not-native English speakers, of course. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Issue 68729 needs attention (language setting for typed text should be set to current input locale)
On 22/11/06, Kirill S. Palagin <[EMAIL PROTECTED]> wrote: ... [language setting for typed text should be set to current input locale] http://qa.openoffice.org/issues/show_bug.cgi?id=68729 Rather on the keyboard layout which was used for entering the text, I believe? E.g., I have Belarusian locale active here, but also I have here plenty of bi-lingual texts, tri-lingual even (Belarusian, Russian, English). Strictly locale-based approach would be pointless. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] SRC680_m163: moved sources of LCID definitions and ISO mappings
On 19/04/06, Eike Rathke <[EMAIL PROTECTED]> wrote: ... > for CWSs with target OOo2.0.3 and UI-translation-relevant flag enabled > shows several integrations for m163, so translations should use that. okay, thanks.
Re: [l10n-dev] SRC680_m163: moved sources of LCID definitions and ISO mappings
On 11/04/06, Eike Rathke <[EMAIL PROTECTED]> wrote: ... > was integrated for m163. We finally got completely rid of the old class > International and replaced the last remaining bits with true i18n > functionality, even in corners where users will almost never look at. > > A second, for developers more important change introduced with this CWS ... So, should the translations freezed for 2.0.3 align with m163 or with m162 or with m161, then? I see lots of changes since m161, but perhaps this isn't pressing right now? -regards
Re: [l10n-dev] NEW Locale Data Audit - please participate!
On 30 January 2006 20:00, Eike Rathke wrote: ... > > doesn't equal symbol, after all. Perhaps, we should leave ISO code there? > > Safe choice? > > It is safe. Just what do people expect if, for example, they have a Calc > value cell and click the currency format icon? Do they want to see some > sort of symbol or abbreviation, even if more than one charater or glyph, > or the ISO code? If not seeing there one of the "traditional" symbols, they'd expect to see something comprehensible. Let's leave ISO code there, then. > > > Otherwise, I think the primary setting should be "бел. руб.", to > > avoid ambiguity. > > Ambiguity to what? My Cyrillic parser is broken ;-) Ambiguity to Russian currency which is also referenced here and also is named "rouble" (abbreviated "руб.") ... > Tarrifs are something different, in telephone calls we can have a tarrif > of 0.0099 Euro per minute, but the smallest coin is 0.01 Euro (== 1 Cent) > so decimals are 2. What is the smallest amount of money you can have in > your pocket? Okay, 0 decimal places, then. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] NEW Locale Data Audit - please participate!
On 27 January 2006 14:43, Eike Rathke wrote: > > > > 3. gregorian:MonthsOfYear.Month.MonthID // may ... > > Well, I'd still say current ooo setting is marginally better, w/r to ... > If that is the case, then please add it to your CLDR bug report. ... > CLDR doesn't accept it, it was at least worth the try. If there aren't > any official rules, I doubt there's justification to keep the old data. Okay, thanks for the proposition. I'll look into references ASAP. ... > > #1387 CurrencySymbol // BYR > > "руб." or "бел.руб." ... > The string length doesn't matter technically, it should be a choice of > usage if there is no national standard. I guess few people write long > terms for the currency symbol when pricing goods, for example. Don't > know though how the CLDR regards this. Maybe because as long as there is > no standard they use the ISO code instead. In fact, I think such record is of almost no meaning outside the several countries where such cultural artifacts exist traditionally. Abbreviation doesn't equal symbol, after all. Perhaps, we should leave ISO code there? Safe choice? Otherwise, I think the primary setting should be "бел. руб.", to avoid ambiguity. > What about #1395, decimal places of the currency? CLDR states that there > are only integer amounts, OOo includes 2 decimals. Well, trivial currency data here doesn't include decimal places, indeed. OTOH, decimal places (kopecks) are still fairly commonly used, e.g., in tariffs. Bit of over-eagerness on part of CLDR here? > Thanks for the detailed answers. It seems that be_BY is quite > a difficult locale.. Oh, not really. As plain as any. :) -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] NEW Locale Data Audit - please participate!
On 26 January 2006 16:17, Eike Rathke wrote: > On Thu, Jan 26, 2006 at 12:24:05 +0200, Yury Tarasievich wrote: > > Mismatches for be_BY: > > > > 1. gregorian:Eras.Era.EraID // ad, bc > > Locale data is correct in this matter, and CLDR is incorrect. > > Would you mind writing a CLDR bug report? See the audit document for Done. CLDR bug #962 (audit issues #1378 and #1379). > > 3. gregorian:MonthsOfYear.Month.MonthID // may > > Formally, both variants are permissible. Bit of ambiguity here. Let it > > be? > > If it really doesn't matter, I'd align to CLDR then. Well, I'd still say current ooo setting is marginally better, w/r to cultural tradition. It isn't too uncommon for CLDR to err somewhat in such matters, after all. Take the issue of startday of en_GB (present in this audit) for example. Or error in CLDR be_BY currency formats (CLDR issue #963). FWIW, GLIBC locale has non-CLDR version, too. Let it be? > What about the other month name differences that seem to > differ in capitalization? Also both permissible? ... > > 4. gregorian:DaysOfWeek.Day.DayID // tue > > Irrelevant, as there is no standard here on such abbreviations. > > Same here, capitalization differences of other day names? *All* capitalisation-only differences in be_BY section of this audit are just a matter of different presentations. Speaking *strictest*, Belarusian grammar doesn't regard names of days and months as proper nouns, so CLDR is possibly bit more correct here, disregarding that names are often capitalised in definitions like this, with no consideration for grammars' rules. Your decision, I think. > I assume OOo's BYR CurrencySymbol р. instead of BYR is correct? Please > include that in your CLDR bug report then. Well, after re-checking with CLDR tables and ooo locales, what ought to be here is (numbers of audit issues): #1383 CurrencyID // BYR "BYR" (as per ISO 4217 and per National Bank regulation) #1387 CurrencySymbol // BYR "руб." or "бел.руб." (there really is no such symbol at the moment, but the above abbreviations are the ones commonly used for that purpose. I have no idea whether these are acceptable w/r to string length, however. If not, then previous choice of "р." would be acceptable, too.) #1391 CurrencyName // BYR "беларускі рубель" (if name is to be in national language, then CLDR is right here) -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] NEW Locale Data Audit - please participate!
On Wed, 25 Jan 2006 22:22:40 +0200, Eike Rathke <[EMAIL PROTECTED]> wrote: I created a new locale data audit document, 320kb http://l10n.openoffice.org/nonav/i18n_framework/cldr/LocaleDataAudit_OOo202.html that does a comparison between locale data as of OOo m151 and CLDR 1.3. For details and description please see the document. ... Mismatches for be_BY: 1. gregorian:Eras.Era.EraID // ad, bc Locale data is correct in this matter, and CLDR is incorrect. 2. LC_CTYPE // ThousandSeparator Non-breaking space is preferred, so CLDR is more correct in this. 3. gregorian:MonthsOfYear.Month.MonthID // may Formally, both variants are permissible. Bit of ambiguity here. Let it be? 4. gregorian:DaysOfWeek.Day.DayID // tue Irrelevant, as there is no standard here on such abbreviations. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Article of %PRODUCTNAME
On 20 December 2005 16:58, Marko Gronroos wrote: > On Sun, 18 Dec 2005, [ISO-8859-2] Tímár András wrote: > > This means that there is a conflict between the StarOffice translation > > and the community OpenOffice.org translation. > > The %PRODUCTNAME is problematic in Finnish too, but for a different reason. > Finnish uses inflections a lot. ... > I believe the same problem is in many other languages too ... > How have you solved this? E.g., re-phrasing in order to have such inflection, which requires un-changed form of noun. :) -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Native (Cyrillic, etc.) alphabetical numbering - an alternative proposal
On 19 December 2005 13:58, Mikhail Balabanov wrote: > - Overflow mode (combo box) ... > Overflow mode (couldn't come up with a better name): ...better make it "Out-of-letters mode". More comprehensible and easily translated, too. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] Belarusian builds?
Hi folks, If someone is doing builds+langpacks for several languages on regular basis, could you please adopt one more language code (Belarusian, be-BY)? -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Cyrillic alphabet numbering
On 16 December 2005 17:29, Danilo Šegan wrote: > 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. ... > 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 :) Hehe, in olden days, if you had a list that long, you weren't structuring your information right. :) Even so, set of allowed letters should be locale-bound, or even customizable. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Cyrillic alphabet numbering (was Bulgarian Cyrillic alphabet numbering.)
On 15 December 2005 12:13, Hristo Simenov Hristov wrote: > On Thursday 15 December 2005 10:35, Yury Tarasievich wrote: ... > > Obviously, such signs aren't used in numbering (itemization) here. So, if > > Bulgarian folks would manage to generalize their modification, that'd be > > good. > > Ok people. I see that I'm not undestand well. > I'll try to explane more. ... > The patch adds 4 Cyrillic numberings: > 1. А, Б, ..., Аа, Аб > 2. а, б, ..., аа, аб > 3. А, Б, ..., Аа, Бб > 4. а, а, ..., аа, бб ... 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. 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. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Cyrillic alphabet numbering (was Bulgarian Cyrillic alphabet numbering.)
On 14 December 2005 18:28, Rail Aliev wrote: > On 18:03, Wed 14.12.05, Hristo Simenov Hristov wrote: > >By localizable I mean the index to be localizable. > >here an example: > >А, Б, ..., Аа, Аб (Български) > >А, Б, ..., Аа, Аб (Bulgarian) > > > >А, Б, ..., Э, ..., Аа, Аб (Руски) > >А, Б, ..., Э, ..., Аа, Аб (Russion) > > > > > >I hope that it is clear now > > Localizable means you can translate it using localize.sdf, isn't it? I'm > not sure if there is a need to all languages to translate such thing. > > Or you mean localazible hardcoded maps for each different language? I think Hristo means that localedata could embrace set(s) of national characters, which are allowed in itemization. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Cyrillic alphabet numbering (was Bulgarian Cyrillic alphabet numbering.)
On 14 December 2005 17:45, Tomislav Randjic wrote: > I have to admit that I'm not sure what 'alphabet numbering' _exactly_ > means as I am very new to this i18n/l10n stuff, but being rare Serbian > here I thought this info will help. Our alphabet: > > А Б В Г Д Ђ Е Ж З И Ј К Л Љ М Н Њ О П Р С Т Ћ У Ф Х Ц Ч Џ Ш > > > Yeah, give it a try, please. E.g., all equivalent East Slavonic systems > > forbid "HARD SIGN" (Ъ) in numbering. > > I believe we don't have them neither, but to be sure - please - > somebody explain me in short what a hard sign is (Ю, Я, Й and Ь we > don't use at all).. > > hope this helps, I know it looks like I came from Mars :) Without going into technicalities, in Eastern Slavonics hard and soft signs (and in Belarusian there's no hard sign but apostrophe instead) mark the palatalization of sounds. Hard with hard sign, soft with soft sign. :) Not the case with Bulgarian, I believe. To have a rough idea what hardsign/apostrophe "sounds" like here, try to say "money", but before pronouncing "-n-" try to quickly press tip of your tongue to the palate just near the back of the upper row of teeth, then releasing it quickly just before pronouncing "-ey". Obviously, such signs aren't used in numbering (itemization) here. So, if Bulgarian folks would manage to generalize their modification, that'd be good. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Cyrillic alphabet numbering (was Bulgarian Cyrillic alphabet numbering.)
On 14 December 2005 17:15, Hristo Simenov Hristov wrote: ... > Bulgarian alphabet numbering is: А, Б, В, Г, Д, Е, Ж, З, И, К, Л, М, Н, О, > П, Р, С, Т, У, Ф, Х, Ц, Ч, Ш, Щ, Ъ, Ю, Я. > We do not use Й and Ь in the numbering. ... > One member of our team suggest to make them localizable. > I'll research this thing is it posiible and I'll write back here what is > the result. Yeah, give it a try, please. E.g., all equivalent East Slavonic systems forbid "HARD SIGN" (Ъ) in numbering. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Armenian localization
On 6 December 2005 13:17, David Fraser wrote: > Yury Tarasievich wrote: > >On 6 December 2005 08:30, David Fraser wrote: > >>Artavazd Mertarjyan wrote: > > > >... > > > >>The _: is used to distinguish between different strings with the same > >> text. You can choose how this works with the option --duplicates to > >> oo2po > > > >...and you may be interested in fact kbabel 3.5 allows to have duplicates > > with the msgcontxt (or whatever it's called) expansion of the gettext > > files format. > > Yes, KDE is where we got this from. Is there something new in KDE 3.5 > here? (KBabel is actually version 1.10...) So they told me... And kbabel there presumably should be 1.11... But this is hearsay, for I haven't yet compiled nor even source-browse kdesdk-3.5 by myself. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Armenian localization
On 6 December 2005 08:30, David Fraser wrote: > Artavazd Mertarjyan wrote: ... > The _: is used to distinguish between different strings with the same text. > You can choose how this works with the option --duplicates to oo2po ...and you may be interested in fact kbabel 3.5 allows to have duplicates with the msgcontxt (or whatever it's called) expansion of the gettext files format. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Mess of translated and English strings in the UI
On 22 November 2005 10:32, Hristo Simenov Hristov wrote: > I have buidled the OOo m139 with our translation (GSI_bg.sdf) and I have > strange behaviour after install. In the UI menus and dialogs I have a mess > of Bulgarian and English strings. > What's going on? Why is this strange behavour? We are trnaslated all UI > strings and part of the help strings. Did you clear the registry/cache directory? -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Bulgarian Cyrillic alphabet numbering.
On 16 November 2005 10:40, Ain Vagula wrote: > 2005/11/16, Hristo Simenov Hristov <[EMAIL PROTECTED]>: > > On Wednesday 16 November 2005 09:56, Ain Vagula wrote: > > > 2005/11/16, Yury Tarasievich <[EMAIL PROTECTED]>: ... > > > > Practice of such numbering doesn't seem to exist in Russian or > > > > Belarusian. At least I can't find it in official documentation > > > > standards. > > > > > > Look at Russian Criminal Law :) > > > http://zakon.kuban.ru/uk/uk_gl16.htm > > > There is a quite long example from a to n in very beiginning. > > > Seems, that characters with umlaut or tilde are not used. Well... This URL contains only one-lettered sub-itemizing, which *is* allowed, which is no news. However, what *I'm* talking about *is* two-lettered sub-itemizing is *not* allowed, at least officially. Also, "hard sign" and "soft sign" are never allowed, one letter or several. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Bulgarian Cyrillic alphabet numbering.
On 16 November 2005 07:23, Hristo Hristov wrote: ... > Unfortunately it can be used for every Cyrillic language because other > languages have other letters included. For example in Russian there is Ы, > Э, Ё, in the other languages are the same. So, this numbering will be > usable only for Bulgarian, sorry :(. But other NLC can use this patch when > it is ready to add their alphabet numbering. Practice of such numbering doesn't seem to exist in Russian or Belarusian. At least I can't find it in official documentation standards. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] SW Inter-character spacing and other problems
On 11 November 2005 13:37, Rajeev Joseph Sebastian wrote: > On Friday 11 November 2005 15:46, Yury Tarasievich wrote: ... > > Yes, if you are talking about B/W corruption (experienced with > > unichrome). If you are talking about something else, try to rephrase. > > This isn't much about l10n, anyway. > > No, it is not "b/w corruption" whatever that means. Basically, as an Should be "B/W bitmaps (like in menus strings) corruption". Now I see that's not your case. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] SW Inter-character spacing and other problems
On 11 November 2005 10:01, Rajeev Joseph Sebastian wrote: > On Friday 11 November 2005 13:05, Yury Tarasievich wrote: > > On 11 November 2005 07:24, Rajeev Joseph Sebastian wrote: > > ... > > > > > 3) cursor handling: the cursor behaves very badly. Sometimes, the > > > cursor actually overlaps the glyph of a character ! It seems to be some > > > cumulative error addition, since the error is not apparent at the ... > > Is this reproducible on different machines? If not, check the brand of > > graphics adapter in your machine. > > Are you serious ? Yes, if you are talking about B/W corruption (experienced with unichrome). If you are talking about something else, try to rephrase. This isn't much about l10n, anyway. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] SW Inter-character spacing and other problems
On 11 November 2005 07:24, Rajeev Joseph Sebastian wrote: ... > 3) cursor handling: the cursor behaves very badly. Sometimes, the cursor > actually overlaps the glyph of a character ! It seems to be some cumulative > error addition, since the error is not apparent at the beginning of lines, > but only after some sequence is traversed. (btw, this is not something that > is caused by the line breaker, since it was always a problem). Is this reproducible on different machines? If not, check the brand of graphics adapter in your machine. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOo 2 and locales
On 28 October 2005 17:10, Redlet wrote: > > Or even, if you are happy with m134, I could change this thing for you in > > my own build copy and see what comes out. Email me exact changes in > > locale you want to yury_tarasievich at yahoo.com. > > My only need is to replace the ',' decimal separator by a '.' in the fr_FR > locale. Sorry, I see I didn't send an answer in time. I've had the changed data built on the same day, but, unfortunately, building on other platform doesn't suffice, as the locales binary data is put in platform-specific shared library. You've got to get somebody to build this for you on windows, after all. -cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOo 2 and locales
On 28 October 2005 12:22, Redlet wrote: > > Why not ask somebody to recompile your milestone of OOO with that > > specific item in fr_FR changed? Then you could just throw in the one or > > several modified .res file(s) over your installation. > > This is precisely what I asked for in my reply to Eike Rathke (Oct. 27th, > 5:29 PM). I think this is the only good solution for me. But I don't know > anybody who could do it for me. Perhaps I could try and do it by myself. > Where can I find a document which explains how it works, how it is possible > to recompile OpenOffice ? What tool do I need for Windows ? Is there any > fitted GNU compiler ? > > You have to know I'm a Delphi programmer. Therefore, if I don't know how to > compile OpenOffice today, I probably can learn and do it tomorrow. I can't help you with compiling on windows (I do mine OOO compiling on freebsd), but thing is you can use .res'es compiled anywhere (e.g., on unix platforms). In my opinion, it would be way easier for you just to look for somebody willing to do this for you on, e.g., linux. Or even, if you are happy with m134, I could change this thing for you in my own build copy and see what comes out. Email me exact changes in locale you want to yury_tarasievich at yahoo.com. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOo 2 and locales
On 28 October 2005 01:15, Redlet wrote: ... > I asked for a solution to replace the ',' decimal separator by a '.'. And I > explaned why I need that. You answered something like "In France, the > official decimal separator is ','. It shouldn't be changed. That's all.". > Sorry but I just can't accept this answer which is a bit sectarian and > peremptory. Why not ask somebody to recompile your milestone of OOO with that specific item in fr_FR changed? Then you could just throw in the one or several modified .res file(s) over your installation. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Releases
On 10 October 2005 10:03, Javier SOLA wrote: > Just passing on information from the "releases" list: > > As things are now, OpenOffice 2.0 is expected on Oct 20th. > > About 2.01 (November) and 2.02 (February), please read: > > http://development.openoffice.org/releases/OpenOffice_org_2_x.html#plan Thanks. What about deadline for submissions of translation updates for 2.0.1 and, eventually, 2.0.2? -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] gettext again (was: [l10n-dev] OOo Localisation Issues)
On 5 September 2005 17:37, Eike Rathke wrote: > On Fri, Sep 02, 2005 at 18:44:27 +0200, Danilo �?egan wrote: > > > As a side note: Opera folks address problem of having context info by > > > adding extensive comments in their plaintext language file. This is > > > comparatively recent practice but of help nonetheless. > > > > We've been doing that in Gnome for more than two years (probably a lot > > longer), because GNU xgettext supports it when extracting translatable > > messages from files. ... > An even bigger question is: would gettext be able to handle it? How does > it scale? Would it be worth the effort? ... Well, I'd agree with Danilo here in that there are fairly advanced translation tools in gettext domain, for one. I won't praise these as "excellent" as Danilo does, for they are quite primitive linguistically, but still they offer functionality which isn't yet matched (?) in this class of software. ... > People tend to only see the mere translation phase and simplicity of > language packs regarding text only, and in these of course using gettext > is much easier. For handling localized icons and such you'd still need > another system, or did that change? And, at least years back when I took ... I'm not familiar with OOO internals, but isn't the string (path) sufficient for addressing of the localized icons? -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOoCon presentation: i18n for l10n
On 1 September 2005 23:36, Ain Vagula wrote: > On 9/1/05, Ivo Hinkelmann <[EMAIL PROTECTED]> wrote: > > Hi Jonathon, > > > > Jonathon Blake wrote: > > > iv) String context. The English word can be translated two or more > > > ways in the target language. [OOo 1.0.0 through 1.1.4 French has some > > > interesting examples of the English being incorrectly translated.] > > > > This is a common problem in string based translation, any suggestion how > > to solve this ? > > We had a talk with David about this some time ago, I believe he is > working on it. Of course, we could make corrections by hand but this > breaks version management inside translation team. We could make all > strings unique, but this makes translation files huge... I dont wanna > see 500 times in one file strings 'Syntax' and 'Example' :) I come to think that this "accreting of similars" may be of more harm than help. The absolute overhead is about 4K strings in interface proper. There are 25K strings total (helpcontent not included) and "accreted" POTs Pavel publishes stand at 21K. Straightforwardly, 4K strings is (by my extrapolation) about 8 man-hours of translating work. If it can be organized to flow uninterrupted, of course. And uninterrupted flow suggests context ready at hand. Not searching in helpcontent, not hunting in program sources. (When doing my own translation, I had to resort to all of this, sometimes even to look into German counterparts of English terms :) Then, there are specific-knowledge terms which translator may or may not be familiar with. E. g., financial, statistical and mathematical terms in spreadsheet module, which, obviously, have to be translated *accurately*. And while de-accreting things like ``Syntax'' may be wasteful, there are lots of seemingly "easy" terms which "fork" when translated. And, after all, there are such things as kbabel's rough translation, which can fill in similars automatically and fairly quick, leaving to translator only task of confirmation/unconfirmation. As a side note: Opera folks address problem of having context info by adding extensive comments in their plaintext language file. This is comparatively recent practice but of help nonetheless. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] translated licenses?
On 12 August 2005 21:43, Pavel Janík wrote: >From: Yury Tarasievich <[EMAIL PROTECTED]> >Date: Fri, 12 Aug 2005 10:30:15 +0300 > > Hi, > >> But there's no way to include it in sources, excepting the >> platform-specific packages, right? > > yes, currently there is no way to localize this file properly. This is > a bug. Can you please file an issue? :-) Surely I can. Should I? :) I, somehow, didn't realize that that's a matter for the issues, too... :) ...done, with #53274. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] translated licenses?
On 11 August 2005 22:42, Pavel Janík wrote: >From: Claudio F Filho <[EMAIL PROTECTED]> ... >> > How are the translated licenses texts added to the languagepacks? Or >> > should they be added as issues? >> > I'm talking about files LICENSE_ and LICENSE_.html. >> > Thanks. >> >> Is a good idea, but the *bigger* problem is that FSF not recognizes >> the (unofficial) translations. Is a old fight between many contries >> that the > > the file LICENSE_?? doesn't contain the licenses under which OOo is > licensed (LGPL/SISSL) but only contains reference to them: ... Yes and no. Yes, the file does include "real" licenses by reference, but than again, *it* is what user's shown when asked to accept license agreement. So... > I think this is perfectly acceptable to be translated... But there's no way to include it in sources, excepting the platform-specific packages, right? -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] translated licenses?
Hi, How are the translated licenses texts added to the languagepacks? Or should they be added as issues? I'm talking about files LICENSE_ and LICENSE_.html. Thanks. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] translated string containing space gets truncated after compilation
Ivo Hinkelmann wrote: I have not yet understand the issue ... Can you please first provide me with the issue id ? Are you sure that you have the right string ? Please paste your generated file: sfx2//misc/appl/sfx.src Here's what's in ooo_SRC680_m121_src/sfx2/unxfbsd.pro/misc/appl/sfx.src, in section for STR_NONAME (first char is tab, value has space between words, lines end with CR+LF): String STR_NONAME ... Text[ be-BY ] = "Без назвы"; ... I've attached this snippet, too. This string after build and install, shows only first word in combolist. BTW, this problem also happens in (somewhat dated) installation of m106. The string, both in .sdf and in .src, was identical there, I believe. -regards String STR_NONAME ... Text[ be-BY ] = "Ðез назвÑ"; ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] translated string containing space gets truncated after compilation
Hello, Recently I filed an issue on subject. Description was as follows: If string "Untitled" is translated to something containing space (in my case it was "Без назвы"), then after compilation second word gets truncated, in combolist (tools-customize-macros-save to file) only first word shows. The identity of string is: sfx2 source\appl\sfx.src 0 string STR_NONAME 0 I've got following answer there: --- Additional comments from es Thu Aug 4 08:29:28 -0700 2005 --- This looks to me like an How-To for developper, not a proper OOo issue (other languages already include spaces exactly for this string: "Sans nom", "Sin nome"...). Please ask the dev mailing list. Thanx! I don't know what the howto for developer has got to do with that. String definitely is there in sdf (which is produced by po2oo script), and it definitely isn't (completely) on screen after compilation and installation. Perhaps it affects only Cyrillic (non-Latin) translations there? -regards However, bot in m106 and m121 translation installations - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Strange use of Slide and Page strings in Draw
On 19 July 2005 12:29, Hristo Simenov Hristov wrote: > I'm just a little confused about using of Slide and Page strings. > In the left of OOo Draw we have little pages with strings: Slide 1, Slide > 2, etc. But when in the popup menu we have New page, Delete page, Rename > page. Can we have any solution of that? The user will be also confused of > this. E.g., translate all of them as your local "paper sheet" equivalent, perhaps? As the concept there revolves around physical objects anyway? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] deadlines?
Hello, The deadlines for submitting were may 20 and june 9. Meanwhile, new milestones continue to appear -- pushing translation(s) out of sync. Now, ihi@ tells that one should wait for the next subversion, but perhaps there still exists some procedure for submitting corrections/updates? -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOo 2.0 l10n reminder
On 19 May 2005 09:37, Yury Tarasievich wrote: > On 18 May 2005 15:46, Ivo Hinkelmann wrote: > > your issue #i49429# is assigned to "sba" . I guess you want to assign it > > to "ihi" ?! > > It got assigned all by itself... I'm reassigning it to "ihi", then. Well, looks like I can't modify assignment parameter. I guess you'll have to sort it out between you and "sba" somehow, then?? I don't think it's a good idea to enter a duplicate issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOo 2.0 l10n reminder
On 18 May 2005 15:46, Ivo Hinkelmann wrote: > your issue #i49429# is assigned to "sba" . I guess you want to assign it > to "ihi" ?! It got assigned all by itself... I'm reassigning it to "ihi", then. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOo 2.0 l10n reminder
On 12 May 2005 18:22, Ivo Hinkelmann wrote: > Languages in l10n queue till now: > Estonian , Punjabi , Dutch , Khmer , Bulgarian , British , Croatian > > more ? Belarusian language l10n (aligned with m103, with no helpcontent2) is in issue #i49429# regards (btw, why Pavel marks issues so: #i#? to have some auto-notification or highlighting, perhaps?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] starting two instances of oo.o with different language settings?
On 12 May 2005 11:42, Joerg Barfurth wrote: In m95/freebsd-4, this works: > There used to be a special command line parameter to do that. In OOo > 1.1.x or 2.0 prior to m97 you could do > > soffice -userid=/path/to/alternate/directory ...and this hangs: > soffice -env:UserInstallation=file:///path/to/alternate/directory Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] po2oo error
On 16 May 2005 11:34, dwb wrote: > I've noticed when running po2oo that I get the following error just before > it exits: > > "could not switch language code on > instsetoo_native/inc_openoffice\windows\msi_languages\Control.ulf/LngText/O >OO_CONTROL_243//" > > It's probably been happening for some time and I've just never noticed it > before. Does it matter? It is as I recall either empty string or smth. like \" (I'm getting this same message). Could be ignored perhaps. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOo 2.0 l10n reminder
On 12 May 2005 18:22, Ivo Hinkelmann wrote: > <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> > -->>> Reminder OOo 2.0 translation deadline is 2005 / 5 / 20 <<<-- > <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> > > Languages in l10n queue till now: > Estonian , Punjabi , Dutch , Khmer , Bulgarian , British , Croatian > > more ? Belarusian is done and is in reviewing/editing. It's currently aligned with m95 strings, so I'd like to know what'd be the final milestone for aligning, m103 perhaps? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] starting two instances of oo.o with different language settings?
Hello, Just what subject says, is it possible? I can't find any commandline argument or alike immediately visible. Would be of help for translation editing. Currently, oo.o searches for its previous instance running and ignores starting from, e.g., environment with different locale setting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] lists of terms separated with semicolons?
Hello, I'm having doubts over the translation of lists of terms separated with semicolons, like Left;Center;Right etc. Should they be translated at all? In source code, as far as I could understand, they seem to be used as keys, not as displayed strings. Am I right? Perhaps, it'd better to revert the translated counterparts of these to English originals? And, by the way, the Belarusian translation of 2.0 interface (currently, WITHOUT helpcontent) is ready. It's being reviewed and edited now. So I'd like to re-raise the question of final English templates, so as to be able to "track" the actual final version of strings set. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] translated strings not showing?
On 6 May 2005 11:59, Joerg Barfurth wrote: > Yury Tarasievich wrote: > >>the strings from the toolbar are comming from the xcu files located in > >>officecfg , most res ( .src !) file only contain dialogs. So please go > >>into output tree ( officecfg/unx/misc/* ) to the merged xcu files > >>and look if you can find files containing en-US and de but not your > >>language. > > > > Haha, much simpler than that. There was mix of previously built xcu's > > lying in $HOME/.openoffice... dir. And when these are newer (file > > timestamp) than the respective base xcu in en-US branch in > > /opt/openoffice/.../registry/..., then even newer overrides in > > /opt/openoffice/... do not get used. > > That is not entirely true. The xcu's in $HOME/.openoffice... are > combined with the contents of the ones in /opt/openoffice/... Their > timestamp does not matter. They are if the cache doesn't get in the way. ... > So if you only changed localized data for an existing language, you > should rm $HOME/.openoffice*/user/registry/cache/*.dat after installing. Right, exactly what I did. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] final templates?
When will the freeze for 2.0 translation originals be called? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] translated strings not showing?
On 4 May 2005 15:44, Ivo Hinkelmann wrote: > Yury Tarasievich wrote: > > I have almost complete translation here (excepting the helpcontent2 and > > the sc stuff I was asking about). It is currently based on the m95 > > Pavel's POTs. I can compile and install both language-specific install > > package and language pack. However, despite folders showing "complete" > > status in kbabel, and despite .res files apparently not having > > untranslated content, programs show lots of english strings, e.g., main > > menu and submenus. What could that mean? > > the strings from the toolbar are comming from the xcu files located in > officecfg , most res ( .src !) file only contain dialogs. So please go > into output tree ( officecfg/unx/misc/* ) to the merged xcu files > and look if you can find files containing en-US and de but not your > language. Haha, much simpler than that. There was mix of previously built xcu's lying in $HOME/.openoffice... dir. And when these are newer (file timestamp) than the respective base xcu in en-US branch in /opt/openoffice/.../registry/..., then even newer overrides in /opt/openoffice/... do not get used. > > How do I solve this? I'd like to avoid complete rebuild if possible, > > there's still lot of editing (therefore, rebuilds) to do. > > Usually you can't avoid a rebuild, but you can speed up things by > building only l10n related targets: > > build --all L10N_framework=de My meaning was "complete rebuild from scratch". Luckily, not the issue. ... > > BTW, .res files seem to have no dependencies on localize.sdf files. I > > update localize.sdf's and corresponding .res'es do not get rebuilt, so I > > have to remove them manually. > > h ... there is a dependency from localize.sdf -> .src files -> .srs > files -> .res files I've definitely was getting this kind of problem, just two days ago. Build ended with res'es from Apr 29 and localize.sdf's from May 03. For lack of time, I didn't investigate this, just threw in recursive removing of res'es from build tree. Thought I'd let people know, though, perhaps somebody with better understanding of oo make hierarchy could check if this is a false alarm. One of the subdirs was sw or svx, I recall. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] translated strings not showing?
I have almost complete translation here (excepting the helpcontent2 and the sc stuff I was asking about). It is currently based on the m95 Pavel's POTs. I can compile and install both language-specific install package and language pack. However, despite folders showing "complete" status in kbabel, and despite .res files apparently not having untranslated content, programs show lots of english strings, e.g., main menu and submenus. What could that mean? How do I solve this? I'd like to avoid complete rebuild if possible, there's still lot of editing (therefore, rebuilds) to do. system is freebsd-4, gcc is 3.3.6, openoffice is m95. BTW, .res files seem to have no dependencies on localize.sdf files. I update localize.sdf's and corresponding .res'es do not get rebuilt, so I have to remove them manually. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Localization problem
On 3 May 2005 15:33, Deepu-Abraham wrote: > I am trying to to do build for punjabi language in W2k > machine with cygwin and visual studio Dot Net 2003 for Openoffice 2.0 > after configuring and running everything as said,it builds the en-US files > but for pa-IN(punjabi version ) i get > following error > > ERROR: ScpActions without name ! GID: scp_Copy_License_Html ! Language: > pa-IN in function: get_Source_Directory_For_Files_From_Includepathlist I guess the only thing that'd really help you with this is: include merging of your locale info into build automation, if it's not yet there (see Javier' Sola instructions for the places to do this), then start build from scratch for two languages, en-US and yours. I had very like problems with my build (when throwing in the new locale after building en-US), and the real resolving of them, dependency by dependency, seems beyond mere human's capability. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] fields and functions names in sc/source/ui/src?
Besides the wizards in In POTs made from contents of sc/source/ui/src, there are lots of strings that look very much like field names (or function names). The whole block of strings around ~800-~1500 (financial calculations and other functions) seems to run like this: .1 = function description, .even_number = function (or parameter) name, .odd_number = function (or parameter) description. So, I'd like to make sure, what of these is translatable, and what isn't? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] po2oo messages
Hello, When I'm converting PO's to SDF, I'm getting lots of messages like in the attached file. What could that mean? First guess is some IDs got deprecated, and just aren't there no more (there are, indeed, no such IDs in en-US.sdf)? OTOH, is there a possibility I'm loosing some translation info? processing 227 files... [ ] 0% [ ] 1% [ ] 1% [# ] 2% [# ] 2% [# ] 3% [# ] 3% [## ] 4% [## ] 4% [## ] 4% [## ] 5% [## ] 5% [###] 6% [###] 6% [###] 7% [###] 7% [###] 7% [###] 8% [###] 8% [ ] 9% [ ] 9% [ ] 10% [ ] 10% [# ] 11% [# ] 11% couldn't find key 'effectoptionseffect.xhp#par_idN10703.help' in po #: 0318.xhp#hd_id3149123.3.help.text #: effectoptionseffect.xhp#par_idN10703.help.text msgid "Color" msgstr "" [# ] 11% [# ] 12% [# ] 12% couldn't find key 'liststyles.xhp#par_idN1060A.help' in po #: 01010100.xhp#hd_id3149651.9.help.text #: 01010100.xhp#hd_id3149807.108.help.text #: 0414.xhp#hd_id3155805.8.help.text #: 04160101.xhp#hd_id3153255.3.help.text #: 05030600.xhp#hd_id3155366.21.help.text #: 05210700.xhp#hd_id3149575.9.help.text #: 05350400.xhp#hd_id3153961.18.help.text #: gallery_files.xhp#hd_id3147088.17.help.text #: liststyles.xhp#par_idN1060A.help.text #, fuzzy msgid "Preview" msgstr "Падгляд" couldn't find key 'liststyles.xhp#par_idN10643.help' in po #: 01100200.xhp#hd_id3154046.35.help.text #: 01110100.xhp#hd_id3146794.12.help.text #: 0119.xhp#hd_id3154923.18.help.text #: 0211.xhp#hd_id3148566.26.help.text #: 03150100.xhp#hd_id3152821.3.help.text #: 0410.xhp#hd_id3155535.12.help.text #: 05020300.xhp#hd_id3149263.21.help.text #: 06010601.xhp#par_idN105A1.help.text #: 0613.xhp#par_idN10A66.help.text #: 06140100.xhp#par_idN106F9.help.text #: 06140100.xhp#par_idN10824.help.text #: 06140400.xhp#par_idN10631.help.text #: 06140400.xhp#par_idN1068B.help.text #: 0615.xhp#hd_id3157909.23.help.text #: 06201000.xhp#par_idN105DE.help.text #: 06202000.xhp#par_idN105FF.help.text #: xformsdataname.xhp#par_idN10584.help.text #: liststyles.xhp#par_idN10643.help.text msgid "Delete" msgstr "" couldn't find key 'liststyles.xhp#par_idN1062A.help' in po #: 0218.xhp#hd_id3151381.21.help.text #: 05200200.xhp#hd_id3155893.21.help.text #: 05200300.xhp#hd_id3156346.13.help.text #: 05210300.xhp#hd_id3150772.19.help.text #: 05210400.xhp#hd_id3147620.17.help.text #: 05210500.xhp#hd_id3158432.11.help.text #: 06010601.xhp#par_idN1059A.help.text #: 06140200.xhp#hd_id3150772.15.help.text #: liststyles.xhp#par_idN1062A.help.text msgid "Modify" msgstr "" couldn't find key 'liststyles.xhp#par_idN10611.help' in po #: 05020300.xhp#hd_id3155311.19.help.text #: 05200200.xhp#hd_id3155355.17.help.text #: 05200300.xhp#hd_id3145313.11.help.text #: 05210300.xhp#hd_id3150669.17.help.text #: 05210400.xhp#hd_id3153823.15.help.text #: 05210500.xhp#hd_id3150275.9.help.text #: 0601.xhp#hd_id3153353.24.help.text #: 06010601.xhp#par_idN10593.help.text #: 06040500.xhp#hd_id3149283.8.help.text #: 06140401.xhp#hd_id3154288.37.help.text #: digitalsignatures.xhp#par_idN10581.help.text #: gallery_files.xhp#hd_id3154317.13.help.text #: packagemanager.xhp#par_idN10639.help.text #: xformsdata.xhp#par_idN10604.help.text #: xformsdata.xhp#par_idN10649.help.text #: xformsdataname.xhp#par_idN10568.help.text #: liststyles.xhp#par_idN10611.help.text msgid "Add" msgstr "" [## ] 13% [## ] 13% [## ] 14% [## ] 14% [## ] 15% [## ] 15% [## ] 15% couldn't find key 'floating_toolbar.xhp#par_idN106D9.help' in po #: doc_
Re: [l10n-dev] l10n without helpcontent?
On 20 April 2005 20:12, Ivo Hinkelmann wrote: > Robert , Yury > > I recommend to concentrate on a perfect consistent GUI first instead of > having 80 % GUI / 60 % help translated, ... Exactly my sentiment, however, resources available put a limit to that... :) > but this is up to you. So yes it > is acceptable to submit GSI/SDF without helpcontent2 ! Okay. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] migrate l10nhelp
On 20 April 2005 15:28, David Fraser wrote: > Yury Tarasievich wrote: > > On Wed, 20 Apr 2005 14:06:55 +0300, David Fraser <[EMAIL PROTECTED]> > > wrote: > > ... > > > >> I think it would be better to enable localize to leave out the > >> language in the output if the translation is not present. > >> Then oo2po will pick up that no translation is present and will give > >> a blank msgstr. ... > > Then name it e.g. localize2. Inserting blanks may be not the happiest > > idea though... > > I was meaning rather that localize could leave out a line if there are > no translations present (not insert blanks). This is tricky as there are > multiple translations in a line, which is why it may be better to > produce PO files directly ... then if no translation is present on > merge, none will be inserted And I'd suggest bit of a off-the-wall addition to that -- for *no* translation, insert some sort of unique key or id *plus* original english. I've checked this "technique" already in other translation, and it mightily helps when there's context-dependent semantics in translated term (giving 1-to-n correspondence in translation). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] migrate l10nhelp
On Wed, 20 Apr 2005 14:06:55 +0300, David Fraser <[EMAIL PROTECTED]> wrote: ... I think it would be better to enable localize to leave out the language in the output if the translation is not present. Then oo2po will pick up that no translation is present and will give a blank msgstr. I'm interested what others have to hear about this ... Now that localize is a perl script it may be easier to change it, on the other hand we don't want to break existing systems ... It might even be nice to alter localize so that you can give an option to produce / merge PO files directly (doing an internal conversion to sdf using the translate toolkit) ... Then name it e.g. localize2. Inserting blanks may be not the happiest idea though... -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] l10n without helpcontent?
Is it acceptable to submit GSI/SDF for the *new* language, not having the helpcontent part? I've seen the deadline is May 20, is it right? So I'm fairly confident that the main content (Belarusian) would be ready, however helpcontent is quite another story. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] Re: dev Digest 5 Apr 2005 09:00:33 -0000 Issue 628
On 5 April 2005 12:00, [EMAIL PROTECTED] wrote: > Re: [l10n-dev] Locale data audit for af_ZA > From: > Eike Rathke <[EMAIL PROTECTED]> > To: > OpenOffice l10n dev > Date: > 2005.04.04 17:32:38 +0300 <...> > > I have a number of other locales to add most of these are already glibc > > locales. Is there any easy way to convert a glibc locale to the OOo > > xml? <...> > > Should I just add these new locales as issues? > > We need complete locale data anyway, so having just the issue without > the data wouldn't be of help. And some of glibc locales contain invalid data, too. --regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] building *only* the localization resources?
Hi, Is it actually possible to build only .res files (or what stands for them in 2.0)? The complete (or rather still incomplete) build takes up to 7 gigs (and grows even now), and tries to build everything in the world and does it like forever. Meanwhile, I'd like to just re-generate res-es with translation. If possible, without even building of the rest of the whole thing. Can one somehow short-cut to this? --regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] translation of hotkeys in non-Latin scripts input systems?
Hello, When translating to non-Latin script (to Cyrillic specifically), there's bit of a problem with translating hotkeys (like ~Hotkeys) and accelerators (like Ctrl+O), at least in KDE (and in programs using QT on windows, too). In cyrillic input mode: - combination of ctrl+ produces , not activating the function (e.g. in openoffice 1.1.4); - in menus, ~ works only in cyrillic input modes (activated both by and by alt+). However, there's a good chance that in translated words, there'll be no chars occupying same positions on keyboard as english originals, so those used to hitting e.g. Ctrl+O for "open" will find their motoric skills useless; So what's the recommended policy on translation of hotkeys and accelerators? Just changing them to native script? Or retaining english-based equivalents? If so, what visual form is recommended (e.g., [~H]? ~H?) Or they just may be discarded? --regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
