Re: Maemo localization to officially non-supported languages
. [ As a reminder: D) there should be translations of all UI strings in all supported languages (so that gettext has something to return in all cases it is used) ] Some potential actions: - Extend the script that extracts .mpo/.po/.pot/whatever information from the UI specs so that it can optionally produce msgids of the form logical_id|Engineering English (or whatever is appropriate for pgettext). Can you do this if needed ? ;-) Sure. Can you? No. I can't. It's not that I don't want to. It's that I don't know that programming/scripting language). - Make a script that replaces logical_id with logical_id|Engineering English (or whatever is appropriate for pgettext) in source code. - Tell developers and UI speccers that they can use this approach and that then the logical_ids don't need to be unique anymore and don't need to include the Engineering English as a hint. They need to be unique. No, they don't. The combination of logical_id plus Engineering English needs to be unique. new logical ID = old logical ID + engineering English [1] For example, we have a generic information note dialog that can be parameterized with the text to display and with the label for its single button. Each use of that information note specifies both the text and the button label as new UI strings. Instead, we could specify a specific UI string as the default label of the button (and allow uses to overwrite it.) Put it in a library then so all the applications can use it. Why did you just say that? I can only assume that you didn't really try to understand what I am writing. So I still don't. I guess I'm getting a bit lost. [2] For example, I am right now coding a new statusbar plugin, the UI spec is done, but I have no translations yet. Do I use logical IDs in the code? Of course not, because they are ugly in the UI and they mess up the layout too badly. (And they might not have the right formatting codes.) So I have to go back later and fix that, but my motivation is low because I shouldn't have had to make this mess in the first place. 'logical_is|Engineering English' will also mess up the layout. No, because the logical_id| part will not be displayed. So you want to use gettext contexts ? That's a different issue now. If you are having this problem then you can generate your own PO files from the UI spec. We can work out something. Why would I go to this extra effort if we could fix the process so that the problem disappears? Because the process will not be fixed _now_ and because you are coding that plugin _now_ Also, I am not primarily interested in my own components here. There are things that each individual component owner should do for him/herself, like including the right formatting codes in the logical ids (if we stick with them), and reducing excessive context if that would improve things. But we are talking here about maemo localization to officially non-supported languages. We need to make that happen for all the code we have. Yes and we are discussing the logical IDs problem as if it's a blocker while in fact it's not. A good way is to use gettext and its tools so that Engineering English appears in the msgid, maybe with excessive context in the form of our current logical ids. We could use Engineering English in the msgid only when interacting with 'unsupported' translation efforts, without changing our own processes. (This is your idea, right?) I never said that. I proposed providing them with POT files suited for the open source tools and my suggestion was ignored. Then I discovered it'd be illegal so I'm still following up with our legal team. We could also adopt Engineering English in our msgids internally, since it has advantages over using logical ids and no disadvantages (as far as I can understand the situation). And it would remove the extra hurdle between external and internal translations. The above lines mean that we need to restart this thread... [3] For example, we should have (and use!) the default button label for the information note dialog. The default Gtk ones ? No, the Hildon information note widget. This is for the UI spec writers. No iddea why aren't you using it ;-) [4] For example, we now can change the actual text of a UI string without changing its identifier, and the new text will automatically pop up in the help texts. When making Engineering English a part of the identifier, we would need to adapt the help text. Not a bad thing, I would say, since you get to review whether it all still makes sense. I don't get this one ? Last time I looked, help texts make references to msgids and when they are typeset, the appropriate translation is substituted for that msgid. In a way, the help texts
Re: Maemo localization to officially non-supported languages
* Mohammed Hassan (Please follow mail-followup-to, I read the list) | If the main problem is identifying untranslated strings in the UI, you | could have a bogus locale where you translate all the translatable | strings into their logical IDs. (Which could be added as comments in | the .c file or whatever.) and use that locale as fallback by setting | LANGUAGE. | | No it doesn't help. You will see an English sentence. How can you tell | if it's translated or not ? No, you won't. As an example, you are translating the fish applet from old gnome-utils into nb_NO.UTF8. The msgid is «I am a goldfish». The nb_NO.UTF8 msgstr will be «Jeg er en gullfisk». The nokia_LOGICAL msgstr is «gnome-utils_ui_123». LANGUAGE is set to nb_NO.UTF8:nokia_LOGICAL Now, if an nb_NO.UTF8 translation exists, it will be used and you'll se the Norwegian translation. If it doesn't exist, but the nokia_LOGICAL one does, that one will be used. If neither exists, it will fall back to the msgid. (Another workaround you could trivially do is to log each time gettext has to fall back to the msgid.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Fri, 2007-10-26 at 09:45 +0200, ext Tollef Fog Heen wrote: * Mohammed Hassan (Please follow mail-followup-to, I read the list) | If the main problem is identifying untranslated strings in the UI, you | could have a bogus locale where you translate all the translatable | strings into their logical IDs. (Which could be added as comments in | the .c file or whatever.) and use that locale as fallback by setting | LANGUAGE. | | No it doesn't help. You will see an English sentence. How can you tell | if it's translated or not ? No, you won't. As an example, you are translating the fish applet from old gnome-utils into nb_NO.UTF8. The msgid is «I am a goldfish». The nb_NO.UTF8 msgstr will be «Jeg er en gullfisk». The nokia_LOGICAL msgstr is «gnome-utils_ui_123». LANGUAGE is set to nb_NO.UTF8:nokia_LOGICAL Now, if an nb_NO.UTF8 translation exists, it will be used and you'll se the Norwegian translation. If it doesn't exist, but the nokia_LOGICAL one does, that one will be used. If neither exists, it will fall back to the msgid. Which still doesn't help. Currently if the string is not translated then we mark it in the PO files so we and the developers can tell that it's not yet translated In case a developer is using an incorrect logical ID or a logical it not in the specs, we can still tell that something is wrong. Now if we start using engineering English, we won;;t be able to tell if it's been translated or not or is the developer using the correct logical ID or not. Even if we use the pseudo locale, you still can't easily tell. (Another workaround you could trivially do is to log each time gettext has to fall back to the msgid.) That's a nice idea. -- Localization Engineer OSSO - Nokia Multimedia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Fri, 2007-10-26 at 16:06 +0300, Marius Vollmer wrote: Mohammed Hassan [EMAIL PROTECTED] writes: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. Let's get some precision here: A) a UI string is a abstract entity that is used in the UI of a program B) code is supposed to use the right UI string for the right purpose, as defined by the UI spec C) code is supposed to get the final string to display by passing the UI strings to gettext D) there should be translations of all UI strings in all supported languages (so that gettext has something to return in all cases it is used) E) I guess it should also be visually distinguishable. Right now, a UI string is identified by a symbolic identifier (the 'logical ids'). Right now, things are specified so that there is a separate UI string for (almost) each single mention of a certain UI element in the spec.[1] When talking about getting rid of logical IDs, we mean that we will identify UI strings not by a (ultimately meaningless) symbolic identifier, but by some other form of identifier that already includes the translation of the UI string for one specific language (Engineering English). For example, instead of using ai_bd_confirm_ok ai_bd_confirm_cancel we could identify these twoparticular UI strings with ai_bd_confirm_ok|OK ai_bd_confirm_cancel|Cancel [ The '|' is my way of notating context for pgettext. ] This gets rid of some of the problems of logical IDs. We can now tolerate violations of requirement D, for example. This is important (IMHO) since D is violated frequently during the development of code, and trying to avoid that is nigh impossible.[2] Also, we can now use the gettext suit of tools directly without having to somehow splice the Engineering English back into it so that translators know what is going on even they don't have the UI spec. Also also, developers can know what is going on directkly without having to consult the UI spec. Thus, we could get the benefits of using Engineering English in the code, and keep the benefits of specifying a 'logical' context for each separate UI string. The problem is that the amount of context specification seems excessive. As a second step (or at the same time as step one), I think we should try to reduce the context specifications to a level where it is not excessive but still useful.[3] This requires work and the benefits can be debated. I hope that making the context specification more meaningful will help improve quality since you have less noise to deal with. Luckily, it doesn't need to be done globally; each UI spec / program combo could do it to their own level and on their own schedule. Library specs can be changed in a compatible way. We could use confirm|OK confirm|Cancel for the two UI strings from the example. This has the same level of context as the original (together with the textdomain), but it is already much nicer to have in your code. In other words, we should reduce the context specifications by reducing the number of individual UI strings in the UI specifications. Thus, even when using Engineering English in the code (plus the occasional (or maybe frequent) context specification), each UI string can be reliably identified. We do not have the option anymore of changing the Engineering English without changing the identifier of a UI string. I.e., if we decide to use Edit instead of Details for a certain button, we can't do that without actually changing all occurances of this identifier. This might be considered serious by some. I'd say it is not a bad thing. We need to be able to push changes (not only changes to UI strings) to all the relevant places anyway, and being able to get away without reviewing the impact of a change at the other end is not essential.[4] Gettext tools can help with this in any case. I can only speak for myself. I think the above approach is not bad but it has a few drawbacks (embedded reply). You (us) might like to also speak to all the parties involved ;-) [ Now we get to the reply to your message. You will see a pattern emerge... :-] [context specifications] are used by l10n testing to easily check for untranslated strings This might refer to either the C or the D requirement (i.e., either the code doesn't use gettext for a aprticular UI element, or a language doesn't have a
Re: Maemo localization to officially non-supported languages
Hi, ext Mohammed Hassan wrote: Which still doesn't help. Currently if the string is not translated then we mark it in the PO files so we and the developers can tell that it's not yet translated In case a developer is using an incorrect logical ID or a logical it not in the specs, we can still tell that something is wrong. Now if we start using engineering English, we won;;t be able to tell if it's been translated or not or is the developer using the correct logical ID or not. Engineering English strings can have some prefix that: - marks it as non-translated (e.g. EE) - is unique (e.g. running number like in EE-01234 ) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi, Mohammed Hassan wrote: On Fri, 2007-10-26 at 17:11 +0300, Eero Tamminen wrote: ext Mohammed Hassan wrote: Which still doesn't help. Currently if the string is not translated then we mark it in the PO files so we and the developers can tell that it's not yet translated In case a developer is using an incorrect logical ID or a logical it not in the specs, we can still tell that something is wrong. Now if we start using engineering English, we won;;t be able to tell if it's been translated or not or is the developer using the correct logical ID or not. Engineering English strings can have some prefix that: - marks it as non-translated (e.g. EE) - is unique (e.g. running number like in EE-01234 ) This is also a nice idea. I'd say we should get all the involved parties to discuss this. Btw. As there's also the Engineering English string at the end of msgid, it's only necessary that the running number is unique between msgids having the same English string. - less need for number-range management - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Fri, 2007-10-26 at 17:11 +0300, Eero Tamminen wrote: Hi, ext Mohammed Hassan wrote: Which still doesn't help. Currently if the string is not translated then we mark it in the PO files so we and the developers can tell that it's not yet translated In case a developer is using an incorrect logical ID or a logical it not in the specs, we can still tell that something is wrong. Now if we start using engineering English, we won;;t be able to tell if it's been translated or not or is the developer using the correct logical ID or not. Engineering English strings can have some prefix that: - marks it as non-translated (e.g. EE) - is unique (e.g. running number like in EE-01234 ) This is also a nice idea. I'd say we should get all the involved parties to discuss this. -- Localization Engineer OSSO - Nokia Multimedia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 16:46 +0200, ext Tollef Fog Heen wrote: * Mohammed Hassan | msgfmt will happily provide you with statistics about untranslated | strings and fuzzy translations, with the added bonus that it can be | automated. | | Yes but it will not help differentiation _visually_ between an en_US or | en_GB string and an Engineering English one. | | It will not help quickly identifying the originating UI spec. | | I got myself into this thread to see what can be done to ease the | community involvement. I know that logical IDs are one of the problems | but I'd say it's mainly a problem for developers more than it being a | problem for localzsers. | | Dropping the logical IDs (If it will happen. I simply do not know) will | not happen today or tomorrow. If the main problem is identifying untranslated strings in the UI, you could have a bogus locale where you translate all the translatable strings into their logical IDs. (Which could be added as comments in the .c file or whatever.) and use that locale as fallback by setting LANGUAGE. No it doesn't help. You will see an English sentence. How can you tell if it's translated or not ? -- Localization Engineer OSSO - Nokia Multimedia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Thu, 2007-10-25 at 08:56 +0300, ext Quim Gil wrote: - Logical IDs vs internal processes. I'm still digesting the thread but it looks that it could be done. Won't be easy but it doesn't need to be done all in once (am I right?). Cases like browser or email client could be isolated. Hildon requires anyway its own attention. Etc. This is not a showstopper. l10n can still be done. We can still workaround them. It's just that people started arguing about logical IDs only. Yes no one likes them but they are another issue. - License of English content and translations. I guess what is really relevant is what translators can do with the English content and the works they derive from it. That's mainly the license for the POT files I guess. I'm trying to handle it. - Adding new languages. Technically possible but how to end up offering new/community language variants to end users. The objective would be that user goes to i.e. Esperanto language pack one-click install and after downloading dependencies can activate this language just like they can do now with the supported languages. I'd say this has to be an effort between l10n and i18n. I'm welling to put effort. - Translators, how we help them getting organized. I'd like to discuss that farther rather than the logical IDs problem. -- Localization Engineer OSSO - Nokia Multimedia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi, ext Riku Voipio wrote: Mohammed Hassan wrote: It would be interesting to take our current translations and mine them for the logical ids that map to the same Engineering English, but at the same time have different translations in some language. These are the cases where we would need to use the menu|Open construct in the code instead of the existing Engineering English string. Identifying and handling these cases is where I see a large part of the effort needed to move away from logical ids, so it would be good to get an overview. Multiple logical IDs with the same Engineering English string are needed because the translation might change according to the context. Actually, gettext already has tools to handle same text in different context without using logical id:s http://www.gnu.org/software/gettext/manual/gettext.html#Contexts Unfortunately this doesn't solve the problem. It still needs a code change. The problem with having just Engineering English is following: 1. There's a release with translations 2. Somebody does a translation for a new language and notices that in different contexts different translation needs to be used, but currently *such context is not provided* - whether the context is given as a part of the string or extra parameter to gettext is irrelevant, the required context is missing 3. To change this, code needs to be updated - If gettext context is used, translations don't need to be updated - If context is in the msgid, also other translation need to be updated, but with proper tools that can be automated Only solution for avoiding 3) is having _some_ unique identifier in all strings and this of course doesn't deal with the problems of strings coming from libraries but being shown in different contexts (maybe in some language OK needs to differ according to the text given in the dialog...). Only thing our unique identifiers get right is being uniq (they are not understood by translators without relevant UI specs they miss format parameters and thus give compiler warnings etc). So, there are two solutions to the problem: - Have a process that can deal with code and translation updates between releases, or - Add some context ID to _all_ user visible strings in the code (and rest of the string should contain the correct format parameters, be translator understandable etc) We can use mixed approach depending on component. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Mohammed Hassan [EMAIL PROTECTED] writes: On Tue, 2007-10-23 at 14:01 +0300, Marius Vollmer wrote: ext Mohammed Hassan [EMAIL PROTECTED] writes: What I'd propose is we/I replace the logical IDs with Engineering English in the POT files you use to translate and convert them back upon packaging and building. One immediate problem I see with this is that multiple logical ids can map to the same Engineering English string, so you can't reliably reverse the mapping. I think using msgid_comment can solve that. Yes, I think so, too. The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? I completely understand the FOSS way. I have my own Free Software projects. It's just that the situation is different Yeah, we all know that not all things are the same. But that's a useless argument. Don't try to argue from authority. It would be interesting to take our current translations and mine them for the logical ids that map to the same Engineering English, but at the same time have different translations in some language. These are the cases where we would need to use the menu|Open construct in the code instead of the existing Engineering English string. Identifying and handling these cases is where I see a large part of the effort needed to move away from logical ids, so it would be good to get an overview. Multiple logical IDs with the same Engineering English string are needed because the translation might change according to the context. Yes, of course. Some logical ids map to the same Engineering English, and some map to unique Engineering English strings. I am saying that it would be interesting to get a concrete list of the logical ids that map to the same Engineering English, to get an idea about how much work is needed when moving away from logical ids. For example, I have 9 logical ids that map to OK, and 9 that map to Cancel in the hildon-application-manager .po file: $ msgunfmt /usr/share/locale/en_GB/LC_MESSAGES/hildon-application-manager.mo | grep -B 1 'OK' msgid ai_bd_add_catalogue_ok msgstr OK -- msgid ai_bd_confirm_ok msgstr OK -- msgid ai_bd_license_ok msgstr OK -- msgid ai_bd_new_repository_ok msgstr OK -- msgid ai_bd_notice_ok msgstr OK -- msgid ai_bd_ok msgstr OK -- msgid ai_bd_search_ok msgstr OK -- msgid ai_bd_select_location_ok msgstr OK -- msgid ai_bd_settings_ok msgstr OK What would we do about them? In this case I'd say we don't need any context and just providing one translation for OK is OK. There are other instances where we might need some context. We have enough real-world data in our translations now that we don't need to talk about this in the abstract. Maybe I am getting ahead of you guys here. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. -- Localization Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. msgfmt will happily provide you with statistics about untranslated strings and fuzzy translations, with the added bonus that it can be automated. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 13:54 +0300, David Weinehall wrote: On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. msgfmt will happily provide you with statistics about untranslated strings and fuzzy translations, with the added bonus that it can be automated. Yes but it will not help differentiation _visually_ between an en_US or en_GB string and an Engineering English one. It will not help quickly identifying the originating UI spec. I got myself into this thread to see what can be done to ease the community involvement. I know that logical IDs are one of the problems but I'd say it's mainly a problem for developers more than it being a problem for localzsers. Dropping the logical IDs (If it will happen. I simply do not know) will not happen today or tomorrow. -- Localization Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On ons, 2007-10-24 at 14:14 +0300, Mohammed Hassan wrote: On Wed, 2007-10-24 at 13:54 +0300, David Weinehall wrote: On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. msgfmt will happily provide you with statistics about untranslated strings and fuzzy translations, with the added bonus that it can be automated. Yes but it will not help differentiation _visually_ between an en_US or en_GB string and an Engineering English one. It will not help quickly identifying the originating UI spec. I got myself into this thread to see what can be done to ease the community involvement. I know that logical IDs are one of the problems but I'd say it's mainly a problem for developers more than it being a problem for localzsers. Dropping the logical IDs (If it will happen. I simply do not know) will not happen today or tomorrow. Well, of course, the biggest problems currently is the fact that people are not allowed by the F:ed up license agreement to translate the software... But logical strings ARE a big problems for people doing localisation, unless they're also provided with our localisation documentation that gives all the information about what the different logical IDs represent. Then there's of course the string format issue, but that is indeed a problem mostly for programmers (but it can potentially be a big problem). So if you can manage to convince management that opening all the localisation documents (all lists of logical IDs and their explanations, that is), and Nokia legal that the EULA needs to be rephrased, then I bet most people will be satisfied, but as a programmer I cannot be happy until we get proper strings that have the same parameter format as the real strings, to allow for proper argument checking by the compiler. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi, ext David Weinehall wrote: On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. msgfmt will happily provide you with statistics about untranslated strings and fuzzy translations, with the added bonus that it can be automated. And if you want to check the translation for common errors, something like this can be used: https://gramps.svn.sourceforge.net/svnroot/gramps/branches/gramps22/po/check_po (which of course doesn't work with our unique ID because the msgids are lacking all the required details.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
David Weinehall [EMAIL PROTECTED] writes: [...] but as a programmer I cannot be happy until we get proper strings that have the same parameter format as the real strings, to allow for proper argument checking by the compiler. Yes, but this is independent from whether we use logical ids or not. The practise of using logical ids has made it possible to screw up in this area like we did (because the software is not required to work in its untranslated form), and getting rid of logical ids would mean that we pretty much must get the formatting codes right in the untranslated strings (because now the software can actually be used untranslated), but we don't need to get rid of logical ids if we want to fix this. You can simply tell you UI speccer to put the formatting codes into the logical ids. It would be good if they would do that on their own, and I am sure we just need to make them aware and they will do it by default. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 14:15 +0300, Eero Tamminen wrote: Hi, And if you want to check the translation for common errors, something like this can be used: https://gramps.svn.sourceforge.net/svnroot/gramps/branches/gramps22/po/check_po (which of course doesn't work with our unique ID because the msgids are lacking all the required details.) Interesting. What are the checks performed by this tool ? The code is not documented enough and running it against a normal PO produced meaningless results to me ? -- Localization Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 14:19 +0300, David Weinehall wrote: On ons, 2007-10-24 at 14:14 +0300, Mohammed Hassan wrote: On Wed, 2007-10-24 at 13:54 +0300, David Weinehall wrote: On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. msgfmt will happily provide you with statistics about untranslated strings and fuzzy translations, with the added bonus that it can be automated. Yes but it will not help differentiation _visually_ between an en_US or en_GB string and an Engineering English one. It will not help quickly identifying the originating UI spec. I got myself into this thread to see what can be done to ease the community involvement. I know that logical IDs are one of the problems but I'd say it's mainly a problem for developers more than it being a problem for localzsers. Dropping the logical IDs (If it will happen. I simply do not know) will not happen today or tomorrow. Well, of course, the biggest problems currently is the fact that people are not allowed by the F:ed up license agreement to translate the software... But logical strings ARE a big problems for people doing localisation, unless they're also provided with our localisation documentation that gives all the information about what the different logical IDs represent. Then there's of course the string format issue, but that is indeed a problem mostly for programmers (but it can potentially be a big problem). Our loxalisation documentation is the UI specs ? So if you can manage to convince management that opening all the localisation documents (all lists of logical IDs and their explanations, that is), and Nokia legal that the EULA needs to be rephrased, then I bet most people will be satisfied, I never checked/had a copy of the EULA. I need to know 1st what do you mean by localisation documents. but as a programmer I cannot be happy until we get proper strings that have the same parameter format as the real strings, to allow for proper argument checking by the compiler. This is not my call. Bug the UI spec designer. What I do is to ensure that the format of the translations is the same as the format of engineering English. I guarantee that. -- Localization Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 12:12 +0300, ext Marius Vollmer wrote: ... For example, I have 9 logical ids that map to OK, and 9 that map to Cancel in the hildon-application-manager .po file: $ msgunfmt /usr/share/locale/en_GB/LC_MESSAGES/hildon-application-manager.mo | grep -B 1 'OK' msgid ai_bd_add_catalogue_ok msgstr OK -- msgid ai_bd_confirm_ok msgstr OK -- msgid ai_bd_license_ok msgstr OK -- msgid ai_bd_new_repository_ok msgstr OK -- msgid ai_bd_notice_ok msgstr OK -- msgid ai_bd_ok msgstr OK -- msgid ai_bd_search_ok msgstr OK -- msgid ai_bd_select_location_ok msgstr OK -- msgid ai_bd_settings_ok msgstr OK What would we do about them? In this case I'd say we don't need any context and just providing one translation for OK is OK. Wrong. It would depend on the context and language. Some languages could use something comparable to 'Yes' (or 'OK'), others the verb 'Search', 'Confirm', etc. And what happens when you add a new, more 'context-sensitive' language? BR; Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Kimmo Hämäläinen [EMAIL PROTECTED] writes: Wrong. It would depend on the context and language. Yes, it COULD, fer-crying-out-loudly. :) We have the data now to figure out whether it actually DOES for the set of our supported languages. And what happens when you add a new, more 'context-sensitive' language? We change the code. Simple. Providing unneeded context is bad in my opinion, and the way we do it with the logical ids is excessivly ugly. Also, how do you know whether I use the correct context in my code? Maybe I am using ai_bd_ok for all my OK buttons? In general, we should try to reduce the need for context and complicated translations. The classical example might: Searched in %d files and %d directories. You will never be able to translate this nicely for all languages because of the wierd way they handle plurals, etc, and because of the combinatorial explosion. A better way is: Number of files searched: %d Number of directories searched: %d ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 14:56 +0300, Marius Vollmer wrote: Also, how do you know whether I use the correct context in my code? Maybe I am using ai_bd_ok for all my OK buttons? Testing will reveal it. In general, we should try to reduce the need for context and complicated translations. The classical example might: Searched in %d files and %d directories. You will never be able to translate this nicely for all languages because of the wierd way they handle plurals, etc, and because of the combinatorial explosion. A better way is: Or Searched %d files and directories ;-) -- Localization Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Marius Vollmer [EMAIL PROTECTED] writes: For example, I have 9 logical ids that map to OK, and 9 that map to Cancel in the hildon-application-manager .po file: $ msgunfmt /usr/share/locale/en_GB/LC_MESSAGES/hildon-application-manager.mo | grep -B 1 'OK' msgid ai_bd_add_catalogue_ok msgstr OK -- msgid ai_bd_confirm_ok msgstr OK gettext now also support a third keyword that holds the context info: msgctxt ai_bd_confirm msgid ok msgstr OK -- Karl Eichwalder ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
ext Marius Vollmer [EMAIL PROTECTED] writes: We change the code. Simple. Providing unneeded context is bad in my opinion, and the way we do it with the logical ids is excessivly ugly. Also, we provide excessive context, but not very relevant context. Take ai_bd_new_repository_ok as an example: What does it matter that this is the Application Manager asking you whether it is OK to add a new repository? The relvant context is that it's a OK/Cancel dialog, and that could be encoded with just confirm|OK, maemo-wide. A dialog that just requires ackowledgement could use acknowledge|OK. Doing cleanup work like this would actually increase the quality of translations, I would expect, because the UI speccer could choose a well-known, meaningful context in most cases, instead of just making every string unique. Ok I should shut up now... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 14:56 +0300, Marius Vollmer wrote: Kimmo Hämäläinen [EMAIL PROTECTED] writes: Wrong. It would depend on the context and language. Yes, it COULD, fer-crying-out-loudly. :) We have the data now to figure out whether it actually DOES for the set of our supported languages. 'For the set of our supported languages' -- quoting you -- 'that way lies madness'. You would need to do this verification every time you add a new language, or change the context a bit. And what happens when you add a new, more 'context-sensitive' language? We change the code. Simple. Providing unneeded context is bad in my opinion, and the way we do it with the logical ids is excessivly ugly. You also need to retranslate and test all the supported languages for the new strings (some of that you could maybe automate). Changing the code is the easy part. Why not make the engineering English unique, and use it instead of the logical ids (OK 1, OK 2 ;)), hey, we do it with variable names in code already... Also, how do you know whether I use the correct context in my code? Maybe I am using ai_bd_ok for all my OK buttons? The localisation testers will notice that, sooner or later. In general, we should try to reduce the need for context and complicated translations. The classical example might: Searched in %d files and %d directories. Yeah, but if you reduce the context too much, the language quality will be comparable to a baby's babbling, and soon some man from Tibet will come and kick your ass! ;) You will never be able to translate this nicely for all languages because of the wierd way they handle plurals, etc, and because of the combinatorial explosion. A better way is: Number of files searched: %d Number of directories searched: %d Sure, there are some examples like that. BR; Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 15:14 +0300, Marius Vollmer wrote: ext Marius Vollmer [EMAIL PROTECTED] writes: We change the code. Simple. Providing unneeded context is bad in my opinion, and the way we do it with the logical ids is excessivly ugly. Also, we provide excessive context, but not very relevant context. Take ai_bd_new_repository_ok as an example: What does it matter that this is the Application Manager asking you whether it is OK to add a new repository? The relvant context is that it's a OK/Cancel dialog, and that could be encoded with just confirm|OK, maemo-wide. A dialog that just requires ackowledgement could use acknowledge|OK. As I already said, some languages _cannot_ use 'OK' for those, they have to use the verb, e.g. 'Add'. Maybe we could use some kind of logical propositions to go around this: 'Is it true that you want to add a new repository? True/False' ;) Doing cleanup work like this would actually increase the quality of translations, I would expect, because the UI speccer could choose a well-known, meaningful context in most cases, instead of just making every string unique. Hmm, I cannot imagine how lack of alternatives would help to make better translations. If the translator has to think how to make the translation to fit our 10 different contexts, it cannot make her job easier, and the result will probably be some kind of compromise that does not really fit well any of the contexts. Ok I should shut up now... I agree :) BR, Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 14:56:46 +0300, ext Marius Vollmer wrote: In general, we should try to reduce the need for context and complicated translations. The classical example might: Searched in %d files and %d directories. You will never be able to translate this nicely for all languages because of the wierd way they handle plurals, etc, and because of the combinatorial explosion. A better way is: Number of files searched: %d Number of directories searched: %d That's what ngettext is for... regards, guillem ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On ons, 2007-10-24 at 14:41 +0300, Mohammed Hassan wrote: On Wed, 2007-10-24 at 14:19 +0300, David Weinehall wrote: On ons, 2007-10-24 at 14:14 +0300, Mohammed Hassan wrote: On Wed, 2007-10-24 at 13:54 +0300, David Weinehall wrote: On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. msgfmt will happily provide you with statistics about untranslated strings and fuzzy translations, with the added bonus that it can be automated. Yes but it will not help differentiation _visually_ between an en_US or en_GB string and an Engineering English one. It will not help quickly identifying the originating UI spec. I got myself into this thread to see what can be done to ease the community involvement. I know that logical IDs are one of the problems but I'd say it's mainly a problem for developers more than it being a problem for localzsers. Dropping the logical IDs (If it will happen. I simply do not know) will not happen today or tomorrow. Well, of course, the biggest problems currently is the fact that people are not allowed by the F:ed up license agreement to translate the software... But logical strings ARE a big problems for people doing localisation, unless they're also provided with our localisation documentation that gives all the information about what the different logical IDs represent. Then there's of course the string format issue, but that is indeed a problem mostly for programmers (but it can potentially be a big problem). Our localisation documentation is the UI specs ? Yes, the UI specs, unless we can have the relevant chapters that describe the strings extracted in an easy manner. I know that it's simple to automate for documentation written in sane ways (.tex, for instance), but I dunno if Word and similar abominations support it in an easy manner. So if you can manage to convince management that opening all the localisation documents (all lists of logical IDs and their explanations, that is), and Nokia legal that the EULA needs to be rephrased, then I bet most people will be satisfied, I never checked/had a copy of the EULA. I need to know 1st what do you mean by localisation documents. The relevant information was posted earlier in this thread. but as a programmer I cannot be happy until we get proper strings that have the same parameter format as the real strings, to allow for proper argument checking by the compiler. This is not my call. Bug the UI spec designer. What I do is to ensure that the format of the translations is the same as the format of engineering English. I guarantee that. Well, we're not using engineering English at the moment. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi, On Wed, 2007-10-24 at 15:14 +0300, ext Kimmo Hämäläinen wrote: On Wed, 2007-10-24 at 14:56 +0300, Marius Vollmer wrote: Kimmo Hämäläinen [EMAIL PROTECTED] writes: Wrong. It would depend on the context and language. Yes, it COULD, fer-crying-out-loudly. :) We have the data now to figure out whether it actually DOES for the set of our supported languages. 'For the set of our supported languages' -- quoting you -- 'that way lies madness'. You would need to do this verification every time you add a new language, or change the context a bit. And what happens when you add a new, more 'context-sensitive' language? We change the code. Simple. Providing unneeded context is bad in my opinion, and the way we do it with the logical ids is excessivly ugly. You also need to retranslate and test all the supported languages for the new strings (some of that you could maybe automate). Changing the code is the easy part. Why not make the engineering English unique, and use it instead of the logical ids (OK 1, OK 2 ;)), hey, we do it with variable names in code already... FWIW, here's my 2cents: I don't use localised images simply because i find revolting what is the commonly understood right way of translating english terms to italian and therefore i wouldn't really be of any help. Hence my contribution in that direction is nil. Then enters the logical_ids: I get 8cm long strings on a button that is designed to accept 6-8 characters (btw, that also would be affected by certain localizations, but let's ignore it for the moment). So even where i _could_ be of some help in providing feedback, I cannot because i have no clue of what the logical id means. And i am not going to read the UI specs just for that. I suppose this applies to many others, here. So logical IDs semm to be a nice way to hide away logical errors. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 15:26 +0300, David Weinehall wrote: On ons, 2007-10-24 at 14:41 +0300, Mohammed Hassan wrote: On Wed, 2007-10-24 at 14:19 +0300, David Weinehall wrote: On ons, 2007-10-24 at 14:14 +0300, Mohammed Hassan wrote: On Wed, 2007-10-24 at 13:54 +0300, David Weinehall wrote: On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. msgfmt will happily provide you with statistics about untranslated strings and fuzzy translations, with the added bonus that it can be automated. Yes but it will not help differentiation _visually_ between an en_US or en_GB string and an Engineering English one. It will not help quickly identifying the originating UI spec. I got myself into this thread to see what can be done to ease the community involvement. I know that logical IDs are one of the problems but I'd say it's mainly a problem for developers more than it being a problem for localzsers. Dropping the logical IDs (If it will happen. I simply do not know) will not happen today or tomorrow. Well, of course, the biggest problems currently is the fact that people are not allowed by the F:ed up license agreement to translate the software... But logical strings ARE a big problems for people doing localisation, unless they're also provided with our localisation documentation that gives all the information about what the different logical IDs represent. Then there's of course the string format issue, but that is indeed a problem mostly for programmers (but it can potentially be a big problem). Our localisation documentation is the UI specs ? Yes, the UI specs, unless we can have the relevant chapters that describe the strings extracted in an easy manner. I know that it's simple to automate for documentation written in sane ways (.tex, for instance), but I dunno if Word and similar abominations support it in an easy manner. So if you can manage to convince management that opening all the localisation documents (all lists of logical IDs and their explanations, that is), and Nokia legal that the EULA needs to be rephrased, then I bet most people will be satisfied, I never checked/had a copy of the EULA. I need to know 1st what do you mean by localisation documents. The relevant information was posted earlier in this thread. I joined the thread late. Just checked this: http://lists.maemo.org/pipermail/maemo-developers/2007-October/012057.html I'll see what can be done. but as a programmer I cannot be happy until we get proper strings that have the same parameter format as the real strings, to allow for proper argument checking by the compiler. This is not my call. Bug the UI spec designer. What I do is to ensure that the format of the translations is the same as the format of engineering English. I guarantee that. Well, we're not using engineering English at the moment. Yes but the translations will be valid if we compare them to a reference which is the engineering English -- Localization Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi, Mohammed Hassan wrote: On Wed, 2007-10-24 at 14:15 +0300, Eero Tamminen wrote: And if you want to check the translation for common errors, something like this can be used: https://gramps.svn.sourceforge.net/svnroot/gramps/branches/gramps22/po/check_po (which of course doesn't work with our unique ID because the msgids are lacking all the required details.) Interesting. What are the checks performed by this tool ? The code is not documented enough and running it against a normal PO produced meaningless results to me ? Features: - Like GCC, it checks that the order and type of the format parameters match (I don't think it understands $ though) - It can do same also for Python keywords (Gramps is PyGtk program) - It also notices if: - msgid has unmatched quotes - translation includes the context part - there are unescaped XML special characters (which would mess up e.g. glade files) - translation includes shortcut key but msgid doesn't - the last punctuation characters differ - It counts how many translations are done/fuzzy/missing. In verbose mode it lists these strings along with the message number so that you can locate them easier in something like KBabel or gtranslate. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 16:03 +0300, Eero Tamminen wrote: Hi, Mohammed Hassan wrote: On Wed, 2007-10-24 at 14:15 +0300, Eero Tamminen wrote: And if you want to check the translation for common errors, something like this can be used: https://gramps.svn.sourceforge.net/svnroot/gramps/branches/gramps22/po/check_po (which of course doesn't work with our unique ID because the msgids are lacking all the required details.) Interesting. What are the checks performed by this tool ? The code is not documented enough and running it against a normal PO produced meaningless results to me ? Features: - Like GCC, it checks that the order and type of the format parameters match (I don't think it understands $ though) I use check_msgid_msgstr_format() to compare every translation with the corresponding engineering English string to ensure the format parameters are identical. - It can do same also for Python keywords (Gramps is PyGtk program) Do we need this internally ? Applications developed outside will not be using logical IDs so it's not a big issue. - It also notices if: - msgid has unmatched quotes logical IDs don't contain them. - translation includes the context part - there are unescaped XML special characters (which would mess up e.g. glade files) We don't use any of the above currently. - translation includes shortcut key but msgid doesn't We don;t specify these in the translations. - the last punctuation characters differ I think this worth me implementing it in my tools. - It counts how many translations are done/fuzzy/missing. msgfmt --statistics can identify that ? ;-) -- Localization Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 15:33 +0300, ext Igor Stoppa wrote: Hi, On Wed, 2007-10-24 at 15:14 +0300, ext Kimmo Hämäläinen wrote: On Wed, 2007-10-24 at 14:56 +0300, Marius Vollmer wrote: Kimmo Hämäläinen [EMAIL PROTECTED] writes: Wrong. It would depend on the context and language. Yes, it COULD, fer-crying-out-loudly. :) We have the data now to figure out whether it actually DOES for the set of our supported languages. 'For the set of our supported languages' -- quoting you -- 'that way lies madness'. You would need to do this verification every time you add a new language, or change the context a bit. And what happens when you add a new, more 'context-sensitive' language? We change the code. Simple. Providing unneeded context is bad in my opinion, and the way we do it with the logical ids is excessivly ugly. You also need to retranslate and test all the supported languages for the new strings (some of that you could maybe automate). Changing the code is the easy part. Why not make the engineering English unique, and use it instead of the logical ids (OK 1, OK 2 ;)), hey, we do it with variable names in code already... FWIW, here's my 2cents: I don't use localised images simply because i find revolting what is the commonly understood right way of translating english terms to italian and therefore i wouldn't really be of any help. Hence my contribution in that direction is nil. Then enters the logical_ids: I get 8cm long strings on a button that is designed to accept 6-8 characters (btw, that also would be affected by certain localizations, but let's ignore it for the moment). So even where i _could_ be of some help in providing feedback, I cannot because i have no clue of what the logical id means. And i am not going to read the UI specs just for that. I suppose this applies to many others, here. So logical IDs semm to be a nice way to hide away logical errors. You are not supposed to provide feedback (It's greatly appreciated if you do for sure). All the above problems can be solved. POT files (With logical IDs as msgids and engineering english as msgstrs) can be generated from the UI specs easily. I can provide them too. All your problems can be solved ;-) -- Localization Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, Oct 24, 2007 at 03:08:13PM +0300, Mohammed Hassan wrote: On Wed, 2007-10-24 at 14:56 +0300, Marius Vollmer wrote: In general, we should try to reduce the need for context and complicated translations. The classical example might: Searched in %d files and %d directories. You will never be able to translate this nicely for all languages because of the wierd way they handle plurals, etc, and because of the combinatorial explosion. A better way is: Or Searched %d files and directories ;-) Provided that you use ngettext(3) instead of gettext(3). Marius Gedminas -- 11. Are you at least tracking the number of users of retchmail? As far as I know, retchmail has exactly three users. -- http://open.nit.ca/wiki/index.php?page=RetchMail signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Eero Tamminen [EMAIL PROTECTED] writes: In general, we should try to reduce the need for context and complicated translations. The classical example might: Searched in %d files and %d directories. You will never be able to translate this nicely for all languages because of the wierd way they handle plurals, etc, and because of the combinatorial explosion. Translator can change the order of the arguments with $. See man fprintf and the Single Unix Specification. Yep, I know. Will it be enough? I found this interesting: http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod#A_Localization_Horror_Story:_It_Could_Happen_To_You ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On ons, 2007-10-24 at 17:53 +0300, ext Marius Vollmer wrote: Eero Tamminen [EMAIL PROTECTED] writes: In general, we should try to reduce the need for context and complicated translations. The classical example might: Searched in %d files and %d directories. You will never be able to translate this nicely for all languages because of the wierd way they handle plurals, etc, and because of the combinatorial explosion. Translator can change the order of the arguments with $. See man fprintf and the Single Unix Specification. Yep, I know. Will it be enough? I found this interesting: http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod#A_Localization_Horror_Story:_It_Could_Happen_To_You Well, that example assumes that the programmer hasn't read the manual of gettext, and thus does not know about ngettext. A clueless programmer can always mess up. News at eleven. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi, Marius Vollmer wrote: Eero Tamminen [EMAIL PROTECTED] writes: In general, we should try to reduce the need for context and complicated translations. The classical example might: Searched in %d files and %d directories. You will never be able to translate this nicely for all languages because of the wierd way they handle plurals, etc, and because of the combinatorial explosion. Translator can change the order of the arguments with $. See man fprintf and the Single Unix Specification. Yep, I know. Will it be enough? I found this interesting: http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod#A_Localization_Horror_Story:_It_Could_Happen_To_You Thanks, I didn't know that about numbers in Arabic and Russian... Names in Finnish are as bad. E.g. Gramps Genealogy application has ~3000 translatable strings of which a couple of hundred are of a form: %(male)s's %(mother)s living in %(place)s had %(children)d children. Where you replace the string format parameters with names. ...And in Finnish instead of having prepositions, you put them at the end of the words and depending on what they are and how the name ends, some of the letters in between change differently. food - ruoka in food - ruuassa house - talo in house - talossa ruler - viivoitin in ruler - viivoittimessa Basically gettext would need to have language specific parsers[1] to produce good localizations. - Eero [1] A former collegue of mine had implemented the Finnish language morphological model in Z-code, but it needed over 64Kb i.e. more than the old adventure games written in Z-code... :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Wed, 2007-10-24 at 18:22 +0300, ext Eero Tamminen wrote: [1] A former collegue of mine had implemented the Finnish language morphological model in Z-code, but it needed over 64Kb i.e. more than the old adventure games written in Z-code... :-) Which is a mathematical proof that learning Finnish is harder than succeed in old adventure games. ;) Anyway, let me summarize: - Logical IDs vs internal processes. I'm still digesting the thread but it looks that it could be done. Won't be easy but it doesn't need to be done all in once (am I right?). Cases like browser or email client could be isolated. Hildon requires anyway its own attention. Etc. - License of English content and translations. I guess what is really relevant is what translators can do with the English content and the works they derive from it. - Adding new languages. Technically possible but how to end up offering new/community language variants to end users. The objective would be that user goes to i.e. Esperanto language pack one-click install and after downloading dependencies can activate this language just like they can do now with the supported languages. - Fonts (Unicode support), input method (virtual keyboard, handwriting recognition) and other i18n issues. - Translators, how we help them getting organized. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi Jordi, On Mon, 2007-10-22 at 22:43 +0200, ext Jordi Mas wrote: Hello Quim, The current system based on logical strings and not on standard open source practices is open for change though, or at least not-closed to changes. In fact I’m willing to push this feature to the maemo roadmap. A problem here are the implications any change has on code, processes, licensing and such. Nothing that couldn’t be done but since the basic L10n is covered, other features tend to get higher priority and attention. As many other people has pointed out I think that this is a must have step for Maemo. I have to admit it. It's not easy to get rid of them. This will affect the current process we are following. I completely understand that you need proper PO/T files to translate and we need to provide you with them. What I'd propose is we/I replace the logical IDs with Engineering English in the POT files you use to translate and convert them back upon packaging and building. If this is fine then I can start to see what's needed to be done to deliver this :-) At platform level I see these main needs: - The use of standard PO files. Would my suggestion above role this out ? - The possibility to register a new language in the system (the user can switch to it). This is the I18N part. I'm sure they can tell better than me. - The possibility to package a deb packet with all the translations and install it. That'd be a standard debian package I guess ? It can also be automated if we will use a central place/repository to gather all the translations. From the community management perspective there are many ways of organsing it. From going to a system like Pootle or LaunchPad to more simple approaches. One easy to setup scenario is: - A Wiki page to list the localization teams / efforts. - A Wiki page with the I18N requirements / needs are collected. - A mailing list to coordinate the community I18N/L10N efforts. - An automatic generated PO statistics files for every language, like GNOME's Damned Lies. (nice to have) - Access to a Subversion space to upload the translations. May be makes sense to move all of this to a Wiki page (community localization?) and start collecting all this feedback there. If such a system is put in place, I can help testing the whole process and tools help to translate (I hope with other folks) the system into Catalan. Let's not go into details like the system we use to manage the translations and stuff. I like the wiki idea so I'd vote for that :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
ext Mohammed Hassan [EMAIL PROTECTED] writes: What I'd propose is we/I replace the logical IDs with Engineering English in the POT files you use to translate and convert them back upon packaging and building. One immediate problem I see with this is that multiple logical ids can map to the same Engineering English string, so you can't reliably reverse the mapping. (Also, the code itself should start using Engineering English itself, of course, to make it more useful to external developers that don't have the UI specs, and because that is how God intended it to be done. :-) It would be interesting to take our current translations and mine them for the logical ids that map to the same Engineering English, but at the same time have different translations in some language. These are the cases where we would need to use the menu|Open construct in the code instead of the existing Engineering English string. Identifying and handling these cases is where I see a large part of the effort needed to move away from logical ids, so it would be good to get an overview. Once that has been dealt with, we could consider using your scheme, or we could consider Engineering English instead of logical ids everyhwere in our processes. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Tue, 2007-10-23 at 14:01 +0300, Marius Vollmer wrote: ext Mohammed Hassan [EMAIL PROTECTED] writes: What I'd propose is we/I replace the logical IDs with Engineering English in the POT files you use to translate and convert them back upon packaging and building. One immediate problem I see with this is that multiple logical ids can map to the same Engineering English string, so you can't reliably reverse the mapping. I think using msgid_comment can solve that. (Also, the code itself should start using Engineering English itself, of course, to make it more useful to external developers that don't have the UI specs, and because that is how God intended it to be done. :-) The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) I completely understand the FOSS way. I have my own Free Software projects. It's just that the situation is different It would be interesting to take our current translations and mine them for the logical ids that map to the same Engineering English, but at the same time have different translations in some language. These are the cases where we would need to use the menu|Open construct in the code instead of the existing Engineering English string. Identifying and handling these cases is where I see a large part of the effort needed to move away from logical ids, so it would be good to get an overview. Multiple logical IDs with the same Engineering English string are needed because the translation might change according to the context. Once that has been dealt with, we could consider using your scheme, or we could consider Engineering English instead of logical ids everyhwere in our processes. -- Localization Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Mohammed Hassan wrote: It would be interesting to take our current translations and mine them for the logical ids that map to the same Engineering English, but at the same time have different translations in some language. These are the cases where we would need to use the menu|Open construct in the code instead of the existing Engineering English string. Identifying and handling these cases is where I see a large part of the effort needed to move away from logical ids, so it would be good to get an overview. Multiple logical IDs with the same Engineering English string are needed because the translation might change according to the context. Actually, gettext already has tools to handle same text in different context without using logical id:s http://www.gnu.org/software/gettext/manual/gettext.html#Contexts ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Pada hari Senin, tanggal 22/10/2007 pukul 22:43 +0200, ext Jordi Mas menulis: - The possibility to register a new language in the system (the user can switch to it). Let's start with this: https://maemo.org/community/wiki/i18n/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Pada hari Senin, tanggal 22/10/2007 pukul 22:43 +0200, ext Jordi Mas menulis: - The possibility to register a new language in the system (the user can switch to it). Let's start with this: https://maemo.org/community/wiki/i18n/ What's the idea of this page? Ask for a better way to do that or explain how do you can do that? As I say on a previous mail, if you want to add a new language in the system the fast and simply way is: * Dowload the package posix-locales, modify debian/rules to add the locale you want to add, recompile the package and install it on the device. * Modify the extra-languages gconf property in order to see the new language on the osso-languageregional applet (to allow the user to select it): gconftool-2 -s /apps/osso/applet/languageregional/available_languages -t list --list-type string [gl_ES] But this allow the user to select the language as gl_ES, very non-intuitive. It could be a good idea to document it, at least meanwhile we haven't a better way to do that. Anyway, IMHO, this process should be improved, for example, allow to configure languageregional in order to allow to add new endonyms. Well, perhaps I'm wrong. There are a better way to register a new language in the system? === API ([EMAIL PROTECTED]) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Tue, 2007-10-23 at 16:34 +0200, ext API wrote: Pada hari Senin, tanggal 22/10/2007 pukul 22:43 +0200, ext Jordi Mas menulis: - The possibility to register a new language in the system (the user can switch to it). Let's start with this: https://maemo.org/community/wiki/i18n/ What's the idea of this page? Ask for a better way to do that or explain how do you can do that? As I say on a previous mail, if you want to add a new language in the system the fast and simply way is: * Dowload the package posix-locales, modify debian/rules to add the locale you want to add, recompile the package and install it on the device. * Modify the extra-languages gconf property in order to see the new language on the osso-languageregional applet (to allow the user to select it): gconftool-2 -s /apps/osso/applet/languageregional/available_languages -t list --list-type string [gl_ES] But this allow the user to select the language as gl_ES, very non-intuitive. It could be a good idea to document it, at least meanwhile we haven't a better way to do that. Anyway, IMHO, this process should be improved, for example, allow to configure languageregional in order to allow to add new endonyms. Well, perhaps I'm wrong. There are a better way to register a new language in the system? It's this page: https://maemo.org/community/wiki/i18n-AddNewLanguages Please check the 4th step: 4. That's it. If you see only xx_YY and not Your Language (Your Country) in the applet, then you need to find and fill these fields in the locale data file (then go back to step 1): LC_ADDRESS ... country_name Your Country lang_name Your Language ... END_LC_ADDRESS -- Localization Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi Jordi, On Thu, 2007-10-18 at 21:20 +0200, ext Jordi Mas wrote: Is there any way to translate the UI into a language not supported directly by Nokia? If not, I would be possible from the community to localize the different individual PO files, build a deb pack for this language and deploy it? As other have pointed out, there are annoyances and obstacles. I'm happy to help trying to remove them, though. http://flors.wordpress.com/2007/10/22/how-to-bring-community-l10n-to-the-maemo-platform/ but copied here for convenience: The current system based on logical strings and not on standard open source practices is open for change though, or at least not-closed to changes. In fact I’m willing to push this feature to the maemo roadmap. A problem here are the implications any change has on code, processes, licensing and such. Nothing that couldn’t be done but since the basic L10n is covered, other features tend to get higher priority and attention. Like in other major features, showing interest, lobbying and providing winning arguments help the internal advocates increasing their priority and relevance in our planning work. Two questions that float around are: a) What is the real interest for L10n in the maemo community? What unsupported languages (could) have translators putting pressure, what apps (could) be pushing already L10n forward, what projects like the CJK support (could) be expanding already L10n beyond Nokia’s list of supported languages? (see below) b) Since the feature is about community translation, should it be complemented by any kind of community tools for translation? How to reuse what is already translated and how to orchestrate the rest. Different open source projects have different ways of organizing translations (see for instance GNOME or Ubuntu). We should find the way suiting our needs best. So what do you want? What do you need? Getting into details is appreciated. All the better if it’s in a wiki page several people can edit, and that is linked from maemo’s roadmap wishlist. FYI the OS2008 supports Brazilian Portuguese, Danish, Dutch, English American, English British, Finnish, French, French Canadian, German, Italian, Norwegian, Portuguese, Russian, Spanish, Latin American Spanish and Swedish. The Nokia N810 hardware keyboard has the following variants: English, German, French, Italian, Russian, Spanish-Portuguese and Scandinavian. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi Jordi, On Thu, 2007-10-18 at 21:20 +0200, ext Jordi Mas wrote: Is there any way to translate the UI into a language not supported directly by Nokia? If not, I would be possible from the community to localize the different individual PO files, build a deb pack for this language and deploy it? As other have pointed out, there are annoyances and obstacles. I'm happy to help trying to remove them, though. http://flors.wordpress.com/2007/10/22/how-to-bring-community-l10n-to-the-maemo-platform/ but copied here for convenience: Recently I was asked to take a look on how easy could be automatize the translation of one app in the n800 (in fact this week, so this is a good coincidence), in concrete to galician. The main problem is translate the current plattform, foremost because this not on standard open source practices you talk about. Anyway there are some other technical problems too. Two details I found this week: * posix-locales: you don't have a dpkg-reconfigure like in a normal debian distributions, and this package only includes the maemo plattform required. I suppose that this is to save storage space. So if you want to include a new language you need to edit the package to include a new language. Well, probably other solution could be install the package locales, although I don't test if this is possible, anyone know? * osso-applet-language-regional: I only found one way to include a new language in this applet: using gconf: gconftool-2 -s /apps/osso/applet/languageregional/available_languages -t list --list-type string [gl_ES] In this way, the combo shows this extra package (well, although only if the locale is available, on the locale -a list, so you need to modify posix-locales as I say). But in this way you see an ugly gl_ES on the combo. This applet has some configuration files to configure the language name, but are compiled in some way, so not configurable if you haven't got the code. Options: * Reimplement a totally-free version of this applet. * Ask *someone* (who?) a way to configure it. === API ([EMAIL PROTECTED]) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hello Quim, The current system based on logical strings and not on standard open source practices is open for change though, or at least not-closed to changes. In fact I’m willing to push this feature to the maemo roadmap. A problem here are the implications any change has on code, processes, licensing and such. Nothing that couldn’t be done but since the basic L10n is covered, other features tend to get higher priority and attention. As many other people has pointed out I think that this is a must have step for Maemo. a) What is the real interest for L10n in the maemo community? What unsupported languages (could) have translators putting pressure, what apps (could) be pushing already L10n forward, what projects like the CJK support (could) be expanding already L10n beyond Nokia’s list of supported languages? (see below) I suggest to separate between internationalization (I18N) needs and localization (I10N). There are languages that you probably could already translate Maemo to (like all the romance languages) but probably the support for others may require asking/lobbing for new features to the I18N team (read here RTL or any other feature). b) Since the feature is about community translation, should it be complemented by any kind of community tools for translation? How to reuse what is already translated and how to orchestrate the rest. Different open source projects have different ways of organizing translations (see for instance GNOME or Ubuntu). We should find the way suiting our needs best. So what do you want? What do you need? Getting into details is appreciated. All the better if it’s in a wiki page several people can edit, and that is linked from maemo’s roadmap wishlist. If we use regular PO files then you can leverage all the tools, glossaries and translation memories from other projects. At platform level I see these main needs: - The use of standard PO files. - The possibility to register a new language in the system (the user can switch to it). - The possibility to package a deb packet with all the translations and install it. - Establish a process for the community can ask/lobby for I18N features. I'm not very familiar with the platform. May be some of this kinds are already possible. From the community management perspective there are many ways of organsing it. From going to a system like Pootle or LaunchPad to more simple approaches. One easy to setup scenario is: - A Wiki page to list the localization teams / efforts. - A Wiki page with the I18N requirements / needs are collected. - A mailing list to coordinate the community I18N/L10N efforts. - An automatic generated PO statistics files for every language, like GNOME's Damned Lies. (nice to have) - Access to a Subversion space to upload the translations. May be makes sense to move all of this to a Wiki page (community localization?) and start collecting all this feedback there. If such a system is put in place, I can help testing the whole process and tools help to translate (I hope with other folks) the system into Catalan. Regards, -- Jordi Mas i Hernàndez, HomePage http://www.softcatala.org/~jmas/ Bloc personal http://www.softcatala.org/~jmas/bloc/ Planeta Softcatalà: http://www.softcatala.org/planet/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Thanks for this insightful email, let's not get it lost. On Mon, 2007-10-22 at 22:43 +0200, ext Jordi Mas wrote: May be makes sense to move all of this to a Wiki page (community localization?) and start collecting all this feedback there. Yes, please. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi Jordi, On Thu, 2007-10-18 at 21:20:11 +0200, Jordi Mas wrote: It seems technically possible to localize the different components to other languages since all the infrastructure is based on intltool and seems very well internationalized. Well, the source code is using logical strings, which I've pointed out in the past being a bad idea (internally and on this list [0]). But then I'm not officially involved with l10n at Nokia. At the time, I wanted to start translating it to Catalan, but I decided I didn't want to waste my spare time dealing with the logical strings. Supposedly some packages might be switching or have switched to engineering english, which is an improvement, but still. Good luck anyway ... regards, guillem [0] http://lists.maemo.org/pipermail//maemo-developers/2006-February/002974.html ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On Thu, Oct 18, 2007 at 09:20:11PM +0200, Jordi Mas wrote: I would like to explore the possibility of localizing Nokia N800 user interface to languages that are not currently localized by Nokia itself[1]. I also. It seems technically possible to localize the different components to other languages since all the infrastructure is based on intltool and seems very well internationalized. However note the licence you have to click through when you download a software image from http://tablets-dev.nokia.com/nokia_N800.php: (b) You may not use, modify, translate, reproduce, or transfer the right ^ to use the Software or copy the Software except as expressly provided in this Agreement. Is there any way to translate the UI into a language not supported directly by Nokia? If not, I would be possible from the community to localize the different individual PO files, build a deb pack for this language and deploy it? This is obviously from a localization point of view without exploring internationalization issues. I think that it would be cool to have a repository of community supported translations that can be installed using a single package that localizes the main components. Marius Gedminas -- I would suggest re-naming rmbdd(). I _assume_ that dd stands for data dependent, but quite frankly, rmbdd looks like the standard IBM we lost every vowel ever invented kind of assembly lanaguage to me. -- Linus Torvalds signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
