Version: (using KDE 4.2.90) Installed from: SuSE RPMs In Arabic world we have six name sets for Gregorian months. We need an option to specify name set for each country (at least for Arabic country for time begin). For more information please see this: http://en.wikipedia.org/wiki/Arabic_names_of_calendar_months
Very interesting, didn't know that. I suspect the correct way for this to be done is to have new localisation files for each local variation such as we have en_GB and zh_TW. I'll post on the l10n list to see what they think.
@John Layt Your suggestion is very good. We have ar_OM and ar_EG ...etc but we need an entry to specify Gregorian month names.
Is it really necessary that the user can choose language names, instead of having them implicitly depend on selected country? E.g. if the language is set as Arabic and country as Algeria, is it reasonable that the user may not want to use Algerian month names, but say Egyptian?
I agree with Chusslove.
@Chusslove: sometime, we need an option to change the months name. For example, If Egyptian guy goes to Lebanon, he will need sometime to familiarize himself to new months names while he get benefit of other local setting of Lebanon (like currency name). I think we should provide a general solution base on the country and after that give an option to override it.
As discussed on the i18n list, reassigning for a solution based on Transcript and the current country code.
There are then two ways to do this. One is clean, but burdensome and may raise false expectations. The other is dirty, but with minimum effort. 1) The clean way would be to add Arabic dialects as new languages to KDE (e.g. ar_EG, ar_LY, etc.), because different month names are precisely the consequence of dialects. User could then simply choose the desired Arabic dialect in language settings. The problem with this solution is maintenance and distribution. It would require adding new languages in (e.g. l10n-kde4/ar_EG/, l10n-kde4/ar_LY/ ...), it would require keeping them in sync with basic Arabic (btw. what is current ar in KDE wrt. dialects? Is it Egyptian?), and releasing packages for these languages too. It would not be necessary that each of the ar_XX languages has all POs, but only those that need modifications (here kdelibs4.po): KDE would be made to automatically look for a translation in ar if there is none in ar_XX. It would also be possible to avoid making separate packages, by stucking ar_XX/ directories into ar/ (e.g. l10n-kde4/ar/ar_EG/, l10n-kde4/ar/ar_LY/...), but still the Arabic team would have to have these extra POs in mind. This solution, while clean in the sense of following the current setup, I feel is a bit too much for total of 12 month names (plus short forms). Also, a user seeing "Arabic (Morroco)" might think he is going to get the Morrocan dialect, at least here and there, and not only month names. You might eveng get reports "I choose XX dialect, but none of the text is in it". 2) The dirty and quick solution is to translate the month names in kdelibs4.po like this: msgid "January" msgstr "" "January0" "|/|" "$[by-country eg,sd,ye 'January1' dz,tn 'January2' ...]" This is relying on the KDE 4 translation scripting feature, the Transcript. Function by-country would pick the month name based on current country, by country code. If no country is matched, the non-scripted translation is used ("January0"). I would add the necessary code for the by-country function into l10n-kde4/ar/scripts/kdelibs/kdelibs4/kdelibs4.js, and that would be it. The problem with this solution is that the user could not choose the month names to be used, at least not right away in GUI. He could do it "manually", though, by creating ~/.transcriptrc with these lines: [ar] dialect=eg which would override locale country in by-country function. In time we might add an option to System Settings, which would do just this, write this file with these lines. (The problem with doing it right away is that it's not clear how and whether to integrate it into GUI -- as I said, technically the clean way is (1), in which case this wouldn't be needed.)
Thinks Chusslove for your input. I prefer the second solution becuase: 1- keeping track of 22 kdelibs4.po files every release is a lot of work for current translating team. We are just 2 persons. 2- There will be a lot of confusing and complains from users and distribution. We will repeat " There is no different apart from Gregorian months names" to every new user. Regarding second solution, it is easy and we need to do it just once. For GUI, we needs a drop-down menu of the country name (or the months set). And it is activated only if the current language is Arabic. Right now, we use Egyptian dialect of the Gregorian months. If you agree can we start work on this for KDE 4.3 and the GUI latter on ?
> [: Zayed Al-Saidi :] > 1- keeping track of 22 kdelibs4.po files every release is a lot of work > for current translating team. We are just 2 persons. Oh, I forgot to count how many would there be actually -- 22 really sounds awful to handle :) > If you agree can we start work on this for KDE 4.3 and the GUI latter on ? Agreed. I'll promptly add the stuff to l10n-kde4/ar/scripts/, in both stable and trunk, and you can start adding scripted parts to those month messages.
Created attachment 35096 [details] new kdelibs4.po file I update the kdelibs4.po to new system, for example this: msgid "January" msgstr "" "يناير" "|/|" "$[by-country iq,sy,lb,pt,jo 'كانون الثاني' ly 'أين النار' dz,tn 'جانفي' mr 'يناير' ma 'يناير']" I install it and try to test it by change my country to Jordon. I does not work. Please test it, maybe I forget some thing or I did something wrong.
Scripted messages in attached kdelibs4.po are fine, but did you install the current language pack from repository? Because it needs to install the l10n-kde4/ar/scripts/kdelibs/kdelibs4.js I've committed today, for the whole thing to work. You can also manually copy this file to the $KDEDIR/share/locale/as/LC_SCRIPTS/kdelibs4/kdelibs4.js.
What I did: 1- I copy your scripts to : l10n-kde4/ar/scripts/kdelibs/ 2- cmakekde 3- I make this directory: $KDEDIR/share/locale/as/LC_SCRIPTS/kdelibs4/kdelibs4.js. But still I can't change months name.
Ok, I made a typo above (as instead of ar in installed location) and might not have been clear alltogether. So, in the repository there's the file: l10n-kde4/ar/scripts/kdelibs/kdelibs4.js (either in stable or trunk). When installed, the location of this file should be $KDEDIR/share/locale/ar/LC_SCRIPTS/kdelibs4/kdelibs4.js As for installation, I didn't use cmakekde so far, but this one should do everything right: $ cd $KDEREPO/branches/stable/l10n-kde4/ $ scripts/autogen.sh ar $ mkdir ar-build && cd ar-build $ cmake ../ar -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` $ make install
@ Chusslove I follow your guide but still I can't change the months names by changing the country.
Argh, I think I know what the problem is. The code in that kdelibs4.js uses a rather recent function to read out the country from KDE settings. I think the 4.2.90 (RC1 or what was it) didn't have it yet. But the code to read the override from ~/.transcriptrc is much older. So, for the testing, create this file, with such content (as above): [ar] dialect=ly
@ Chusslove I have kde4.2.93 and I create the ~/.transcriptrc as your instruction. Nothing changed even the country does not change. Is there any libs required ? Can you commit the kdelibs4.po to /stable/stable/l10n-kde4/ar ?
> I have kde4.2.93 and I create the ~/.transcriptrc as your instruction. > Nothing changed even the country does not change. Is there any libs > required ? (The country code is not supposed to change anywhere visible, but only within that by-country function. No extra libraries are needed, the system is fully internal to KDE libraries.) I forgot to ask, where do you look how the date is displayed? Because, now I see, while I change the country in System Settings, the month name in the preview pane below does not change. Only when I apply the new country, and reopen System Settings (or any other app, naturally) are the month names for the chosen country used. This requires some fixing. > Can you commit the kdelibs4.po to /stable/stable/l10n-kde4/ar ? Done.
> [: Chusslove Illich :] > [...] Only when I apply the new country, and reopen System Settings (or > any other app, naturally) are the month names for the chosen country used. > This requires some fixing. Fixed.
(In reply to comment #17) > I forgot to ask, where do you look how the date is displayed? Because, 1- System Settings preview pane ---> fixed 2- System Settings Calender 3- Plasam panel Calender
> 1- System Settings preview pane ---> fixed As in, it now works for you? Then everything else must work too, possibly requiring a restart of the application or new logging in. > 2- System Settings Calender > 3- Plasam panel Calender Hm, you mean these still don't work, even after you log out/log in to KDE?
(In reply to comment #20) > As in, it now works for you? Then everything else must work too, possibly > requiring a restart of the application or new logging in. I've just updated the kdelibs and I can confirm that 1 and 2 are fixed. I'm now updating the kdebase to see plasma thing. Thanks Chusslove.
Ok, Now I got full desktop and Plasm calendar works properly. Well done Chusslove.
Yay :) Let's not close this bug until GUI stuff is complete too.
What's missing?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!