> After making this change, I assume you're logging out and logging back in to
> test the change.
I did that, plus rebooting: the bug is present either way.
> Are you doing this with Ubuntu Desktop, or with one of the other flavors
> (such as Kubuntu or Lubuntu)?
I'm using Ubuntu Desktop.
> I ca
This bug cost me a lot of time. After last year's Turkish/Turkic-
specific issues, it is quite frustrating to suffer from this generic one
this year.
FWIW, the issue might not be in language-selector per se:
+:
1) .pam_environment is updated after making the non-system-wide change in
language-sel
I ran into a related issue and logged bug 701631.
I'd appreciate your feedback on the following:
i. Has the fix from comment 16 been included in Firefox 8?
ii. Is the following statement correct based on fix referred to in comment 16?
Even if there's a remote version of the lang pack that is compa
Public bug reported:
When setting regional formats (date, etc.) system-wide, authentication dialog
just below the title bar says:
"System policy prevented ..."
This string currently appears to be non-localizable.
P.S. Could be in language support itself, or in policykit, i don't have
time to ve
Public bug reported:
The title bar says: Keyboard Layout "..."
Verified using several locales that it's not localizable.
P.S. I think it's probably in xkeyboard-config (xkb), but don't have
time to verify...
** Affects: ubuntu
Importance: Undecided
Status: New
** Tags: keyboard
I did spend some time trying to locate a package whose localization
files contain these strings, but i haven't been able to find it. I'm
quite sure they are currently not localizable. Alas, I can't spend more
time looking into it.
--
You received this bug notification because you are a member of
Public bug reported:
The following strings on login screen are not localizable:
Recovery Console
User Defined Session
I checked out the French locale, which is usually good with l10n, and
they show in English anyway. So unless i missed something, it's a bug.
P.S. The install i tested it on start
FYI: some other Turk languages like Crimean Tatar (Crimean Turkish) and
Azeri are also affected by this. Hopefully this will be in the main repo
soon, and most users won't upgrade until then...
P.S.
I installed python-gobject 2.28.3-1ubuntu1.1 which is now in proposed, and was
then able to user l
The code fixes are on their way. The last thing left to be fixed is the casing
in the subject of this bug. :)
I look forward to seeing language-centric keyboard preferences UI in stable
releases as well.
Thanks all.
** Summary changed:
- Too many crimean tatar keyboard layouts added for Romani
FYI: the politicized "By country" tab has been dropped in the latest
xkeyboard-config code, and a patch[1] has been submitted to show Crimean
Tatar layouts in a language-centric manner, consistently with how it's
now done for most other layouts. Among other things this patch ensures
that Crimean Ta
> Our options are:
>
> A) Fix libx264 :
> http://git.videolan.org/?p=x264.git;a=commitdiff;h=3d0d9cda1d39239e9f388fe1fce29c9212d0273c
> and
> http://git.videolan.org/?p=x264.git;a=commitdiff;h=5f104e9957cc4b69f7197fecf93648a0e2ae0e59
Since when these 2 patches were ported they resulted in a se
> Easiest/Best fix seems to me to update the x264 package to the latest
revision from the x264 stable branch
Olivier from upstream also said the latest snapshot should be taken:
https://bugzilla.gnome.org/show_bug.cgi?id=633809#c10
He probably also implied "from stable branch".
If it really has b
1. I have mentioned this upstream earlier, but here's an example of a
logical locale-based approach to layouts:
-Language1
|__ Common Layout1
|__ Common Layout2
|__ Common Layout3
-Language2
|__ Common Layout1
|__ Common Layout2
|__ Country1
|__Country1-specific layout1
|__Countr
For starters, Crimean Tatar isn't really related to Mongolian. Mongols
in related territories got assimilated, and their language hasn't had a
major influence on Turk(ic) languages: although some words from
Mongolian have been adopted and are in use. Now to the issue at hand.
> To a large extent,
The steps are described above. To elaborate further, i think the layout isn't
shown unless the user has more than 1 layout in preferences.
I personally think it's a bad requirement/design decision:
if a user has multiple computers, he might not be sure what layout is in a
particular account's pre
> ...
> no point flushing this bug w/ other date
Of course, i meant:
...
no point flushing this bug w/ other data ...
I look forward to hearing from people regarding this issue, now that i
know that this bug isn't in a black hole. :)
--
Bad signatures for 10.04 installer validation: MD5SUM SHA1
I took the liberty to remove upstream testing tag.
I CAN verify CD iso signatures, but not the DVD iso signatures. Until i hear
from somebody a credible report the he/she CAN verify DVD iso signatures,
there's no point flushing this bug w/ other date, because it would only cause
clutter, IMHO.
Hi Jeremy,
thanks for at least getting back to me. However, i think you are on the
wrong track. Have you tried verifying a DVD iso signature (not a CD)? I
get the feeling that you haven't.
This is what i get on a new installation:
$ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB7545
> If i don't here ...
Feeling compelled to show that i'm not illiterate, should have been:
If i don't hear ...
But darn, looks like this bug is in a black hole, so perhaps nobody will
ever see my spelling error. :)
Heck, might as well rant a bit more: Shouldn't people at least be able
to verify
I still can't believe nobody cares about this. Making a valid signature is a
requirement for any release, and should only take a couple of minutes to do.
This should go right up to chain of command to the "President of Ubuntu", but i
can't figure out how to draw some attention to this critical i
I'm surprised nobody speaks out about this.
Not sure which "package" to mark here: perhaps ubiquity is a better fit than
app-install-data-ubuntu...
** Package changed: app-install-data-ubuntu (Ubuntu) => ubiquity
(Ubuntu)
--
Bad signatures for 10.04 installer validation: MD5SUM SHA1SUM SHA256S
That said, the CD signatures from
http://releases.ubuntu.com/releases/10.04/
can be verified.
So this appears to be a dvd-specific issue.
** Package changed: ubuntu => app-install-data-ubuntu (Ubuntu)
--
Bad signatures for 10.04 installer validation: MD5SUM SHA1SUM SHA256SUM
https://bugs.launch
Public bug reported:
MD5SUM, SHA1SUM, and SHA256SUM signatures from
http://cdimage.ubuntu.com/releases/10.04/release/
can't be verified. This makes it questionable whether to proceed w/
installation.
** Affects: app-install-data-ubuntu (Ubuntu)
Importance: Undecided
Status: New
--
Public bug reported:
In my experience, Keyboard indicator doesn't show up on the panel if a
sub-layout is chosen on logon screen, until a (non-sub-) layout is
chosen on logon screen, AND a sub-layout is added to preferred layouts
WHILE in gnome session (THEN, on next logon you can choose a sub-lay
> It's the other way round: the first one in the queue is the outdated
template with 681 strings, and the last one is the updated one I
uploaded with 728 strings.
I stand corrected. I guess i was too tired to notice that the 1st one's
date was the 13th, and not the 14th. Plus, i should have notice
Yes, generating .pot during build should resolve such issues for the
long term. David, thanks for the concrete solution suggestion.
But, just an FYI, as of now, there are 2 .pot files Approved for import
(as seen using David's link above): the first one w/ 728 strings, and
the 2nd one w/ 681 strin
Based on some testing (using Crimean Tatar/Turkish and French locales) after
installing updates of all core packages today, the same issue we had last year
is present this year as well (i'm updating bug title for versions, but not sure
whether it's better to open a completely new bug instead).
I
> Can you take this up with upstream, perhaps?
The latest gdm probably doesn't have any such issues. Fedora 11 Preview
that i tried (both installed, and even Live CD), shows Crimean Tatar
(Crimean Turkish) locale in gdm just fine, and it really made me feel
good when i first saw it. Once i verify
I understand that chances of this bug being treated as a "very high-
priority showstopper bug" are not very high, and it may indeed be too
late to address this in jaunty, but would still like to try and bring
this to the attention of ubuntu-release team for a freeze exception
evaluation.
I've seen
I think if this was considered important, it would still make it on
time, as the official release date is the 23rd, and there's still plenty
of time even until midnight between the 21st and the 22nd.
The question appears to be:
Does this qualify for freeze exception process, considering also that
Turns out Ubuntu is using an old version of gdm, which, unlike 2.24 or 2.26 in
fact does appear to compile locales in. I'm not sure whether the locales are
taken directly from the Ubuntu gdm source file
gdm-2.20.10/config/locale.alias
or an external file maintained by i18n team, but it is quite c
I've added firefox as an affected project, because i believe this used
to be handled there at least in FX 2 times. If that is no longer the
case, please feel free to remove it. Howver, it appears to me the lang
pack build script might be checking for the presence of the translation
under firefox pr
I split out Firefox packaging issue into a separate bug:
https://bugs.launchpad.net/ubuntu/+source/language-pack-crh-base/+bug/363264
This bug is now only about GDM languages list issue.
Hopefully, this will help a bit in tracking and fixing outstanding
issues in a more organized and efficient ma
If needed, i can import crh.xpi again, although i've been assured by
Danilo that the previous import was OK.
P.S. I'm not trying to import it again just yet, due to format and file
name issues experienced prior to the previous import getting
successfully completed, but can re-import it quickly, if
Public bug reported:
Binary package hint: language-pack-crh-base
The firefox translations should be provided by language-pack-crh-base package.
Although the .xpi was imported on the 8th, firefox translations still weren't
provided by language-pack-crh-base after the package was re-built on the
** Summary changed:
- Please enable language support for Crimean Tatar (Crimean Turkish) locale
(crh)
+ Crimean Tatar (Crimean Turkish) locale (crh) is not shown in gdm languages
list, even if language support for crh is added
--
Crimean Tatar (Crimean Turkish) locale (crh) is not shown in gdm
The firefox translation should actually be provided by language-pack-crh-base.
Although the .xpi was imported on the 8th, firefox translation still wasn't
provided by language-pack-crh-base after last Friday's full export from
launchpad.
If it's still possible to fix up language-pack-crh-base p
I am now aware that apparently language-support-crh package isn't
related to gdm languages list, but the following is probably still
related to this bug:
The firefox .xpi import has succeeded, but apparently it's not been released w/
04/10 full export from launchpad. The following package is stil
I was kinda tilted to thinking in that direction after seeing this bug upstream:
https://alioth.debian.org/tracker/index.php?func=detail&aid=311588&group_id=30316&atid=413077
I guess what you mean is that that bug refers to another distro, where
gdm uses iso-codes, and it doesn't apply to Ubuntu y
I wonder whether upgrading
http://packages.ubuntu.com/jaunty/iso-codes
which is currently based on 3.6, to 3.7 or 3.8 would resolve the gdm languages
list issue, although the only additional relevant thing provided w/ those
releases is crh.po files.
P.S.
I don't know whether it matters, but I d
I forgot to mention: i'm wondering if ; character in language name spelling
might be causing such hard to diagnose side effects, because it appears to be a
"reserved" character at least in one the files involved.
Please feel free to change ; to another character, which should be OK
temporarily,
I'm wondering if there is any way to get the gdm languages list issue resolved
before final jaunty release, for which apparently the time is running out.
I'm busy trying to do some last minute translations, but if there's anything i
can do to help resolve the gdm issue, please let me know.
Than
Hi Bryce,
It appears upstream is very likely to take some time for reasons beyond
my control. I give my word that i will do my best in getting this
handled personally or as a 3rd party, but it's hard to estimate the
timeline there at this time. Hopefully it will be taken care of sooner,
rather tha
Despite my inability to manually get it to work, as mentioned in my last
comment, Martin might well be right about /etc/gdm/locale.conf being the
roadblock, and it might start working when the package is built in a manner
that addresses this.
I hope this can be addressed in gdm in time for jaun
It appears we don't have a roadmap for this yet. Could you please
enlighten me on how 1.4 .pot got into launchpad: is it automatically
pulled from xkeyboard-config bazaar project, or TP, or did somebody
manually imported in into launchpad?
Thanks.
--
launchpad xkeyboard-config .pot is obsolete:
> I've imported a .po, and the only out of the ordinary thing i've
noticed is that .pot in launchpad translations is apparently based on
1.4.
FYI on that subject:
https://bugs.launchpad.net/rosetta/+bug/349341
This is not related to this bug per se, but is related to Ubuntu
xkeyboard-config l10n
FYI, i have tried adding the following manually to this apparently generated
file, but it did NOT resolve the gdm issue:
Crimean_Tatar;_Crimean_Turkish(Ukraine) crh_UA
Crimean_Tatar;_Crimean_Turkish(Ukraine) crh_UA.UTF-8
I gave it about 30 minutes, maybe i missed something, but it doesn't
appear
Btw., i don't think .orth could be causing gdm language selection issues, but
is there any chance that it could be a factor?
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/339396
Thanks.
--
Please enable language support for Crimean Tatar (Crimean Turkish) locale (crh)
https://bugs.l
I see that language-support-crh doesn't appear to affect the remaining
gdm issue, but after spending many hours on it today, i still see that
the following issue is outstanding:
crh isn't listed among available languages in the gdm login screen, even
after adding language support for crh locale. S
Turns out when i posted my last update on 03-21, 2 out of 3 packages
were already available since 03-16. This was a good news, because now
language support can be added as user-default language once the user is
logged on.
However, the following package is still not available:
language-support-crh
> OK, the issue is, that the -base package is not generated. We will fix this
> in langpack-o-matic, which builds the
> packages.
Pleaease tell me that this is on track for Crimean Tatar (Crimean
Turkish) language support to be available with the Jaunty release? I
hope very much to be able to tes
Hi Bryce,
Just wanted to let you know that apparently you made the right call to not
include .po (and its derivative configure.in) patches. It appears that those
aspects can be handled by importing a translation on launchpad. Such a
translation may get released w/ a different package in compari
Just a bit more info, in case it's relevant. Alacarte package for some
reason doesn't have a .po import from upstream, although gnome-panel,
which upstream was translated later than alacarte, does have a .po
import from upstream. If this tells you anything, please take it into
account. If not, then
To elaborate on what i meant by "doesn't appear to affect anything", if
i set LANG and GDM_LANG to crh_UA.UTF-8 on a shell in alpha-5, i can
launch a localized app, or vi or gedit a file containing characters of
interest, and there are no font-related issues in the app's UI, or vi,
or gedit.
--
C
Public bug reported:
Binary package hint: fontconfig
My primary motivation is to make sure that Crimean Tatar (Crimean
Turkish) language support is available in jaunty, and no font-related
issues occur. As of now, w/ alpha-5 release, absence of crh.orth doesn't
appear to affect anything. If you a
** Attachment added: "crh.orth waiting to be released upstream."
http://launchpadlibrarian.net/23595739/crh.orth
--
Crimean Tatar/Crimean Turkish (crh) .orth
https://bugs.launchpad.net/bugs/339396
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Also, will users be able to add Crimean Tatar (Crimean Turkish) support from
Language Support menu item once 1 or more of the following packages are
released:
language-pack-crh
language-pack-crh-base
language-support-crh
Just want to make sure whether this is the only "missing link".
Thanks.
-
Hi Arne,
Did you mean you this would be released in mid-March? I tried it today, and no
changes yet: crh is still not available in language selector. Which l10n
packages are available also hasn't changed since Feb. 27:
Available (these packages started to get built in October of last year):
lang
Please let me know if i should attach a patch for this. I could easily make
both packages by tweaking a currently supported locale, and attaching a .tar.
Just 1 question:
Should the contents of
language-pack-crh-base:data/crh/LC_MESSAGES
be included in such a patch?
Thanks.
--
Please enable l
Linking to language selector: that's the best i can think of at the
moment.
** Changed in: language-selector (Ubuntu)
Sourcepackagename: None => language-selector
--
Please enable language support for Crimean Tatar (Crimean Turkish) locale (crh)
https://bugs.launchpad.net/bugs/335307
You receive
Public bug reported:
I believe this might be dependent on automatic language-pack builds for Crimean
Tatar (Crimean Turkish) locale (crh).
In particular, at the moment, the following packages are not being built:
language-pack-crh
language-pack-crh-base
Info that may be needed:
Language code: cr
I agree about upstream, it's just a matter of time before i or somebody
else tries to get it there again.
Bryce, thanks for queuing patch from #21. However, although It is better
than what was released with 1.5-2ubuntu5, i hope we can use the patch
from comment 28 or at least the one from comment
This incremental 5-liner is probably unnecessary, but attaching it just
in case.
** Attachment added: "3a.4-incremental: for incremental Alt-Q-gbreve tweak, and
corrected email address in comments, assuming patch 3a has already been
applied."
http://launchpadlibrarian.net/23092555/xkeyboard-
This could be used to re-apply Crimean Tatar keyboard layouts patch from
scratch.
** Attachment added: "3a.4-complete: everything in 3a that has already been
released, plus Alt-Q-gbreve tweak, and corrected email address in comments."
http://launchpadlibrarian.net/23092430/xkeyboard-config-cr
Just noticed another little formality: i listed my email address
incorrectly as being under gmail.org: it should be under gmail.com.
Sorry about that. In case, anybody actually uses that email address,
it's probably worth correcting.
Two 3a.4 patches (complete and incremental as the last 2 times)
Since apparently the existing debian/patches/107_crh_layouts.patch would
be updated for the Alt-Q-gbreve-related tweaks, this incremental 4-liner
is probably unnecessary, but attaching it just in case.
** Attachment added: "3a.3-incremental: for incremental Alt-Q-gbreve tweak,
assuming patch 3a
This could be used to re-apply Crimean Tatar keyboard layouts patch from
scratch.
Based on today's ubuntu6 and ubuntu7 versions, the same patch file will
be updated, so i suppose this complete patch is probably what's needed
to account for the Alt-Q-gbreve-related tweaks.
** Attachment added: "3a
Actually, the for-consistency change in regular Q layout, now caused a
slight inconsistency and redundancy in custom Q layouts for Romania,
therefore please ignore the previous two 3a.2-* patches. I am very sorry
for not getting it 100% right last night. In the next 2 comments i'm
attaching updated
> Please work constructively with upstream on getting your changes
merged there.
Currently i've been trying to get as much l10n/i18n done as possible for
the next Ubuntu release. At some point, this indeed will need to go
upstream. I can only hope that the constructiveness and objectivity of
whoev
I guess this would be most applicable if Alt-Q gbreve tweak needed to be
in a separate patch file, as opposed to being merged into
debian/patches/107_crh_layouts.
** Attachment added: "3a.2-incremental: for incremental Alt-Q gbreve tweak,
assuming patch 3a has already been applied."
http://la
This could used to re-apply Crimean Tatar keyboard layouts patch from
scratch.
** Attachment added: "3a.2-full: everything in 3a that has already been
released, plus gbreve tweak."
http://launchpadlibrarian.net/23050073/xkeyboard-config-crh-layouts-3a.2-excluding-pot-and-ChangeLog-and-po-and-
Thank you, Bryce! This will make the next Ubuntu release a lot more
interesting.
Unfortunately, i overlooked a little thing in Alt-Q layout, and am
attaching generic patches to take care of that: gbreve, which is a
letter that needs to be available, was inadvertently being overwritten
in Alt-Q. No
297 lines: patch based on patch 2, with updates to exclude any i18n, and
also with shared Q layout having been removed from Romania config (at
least for the time being), with the assumption that its 2 special Q
layouts will satisfy users.
P.S. I've never dealt with ubuntu-specific debdiff so far,
2786 lines: configure.in changes are not included here, w/ the
understanding that if .po is not included, crh needs to not be added to
configure.in.
It would be nice if this patched made it too, so that i18n'ed UI could
be enjoyed. Perhaps this could be included for 1 release only, and
removed rig
Unfortunately, knowing the code is not the only factor, and apparently
by far not the only factor in this case.
What i'm attaching below is the last patch re-factored into 2 pieces:
1. contains only i18n-related changes: .po and configure.in.
2. contains the keyboard layouts; also, shared Q layou
Hi Bryce,
I appreciate your feedback.
It appears to me the only sensible way to proceed is downstream-first:
First of all, 1.6 won't make it into Ubuntu for another 9 months, thus upstream
doesn't make a difference right now. I probably shouldn't even have gone that
route, after i missed 1.5 c
The fix isn't really released as it is shown.
** Changed in: xkeyboard-config
Importance: Unknown => Undecided
Bugwatch: freedesktop.org Bugzilla #19730 => None
Status: Confirmed => New
--
Patches for Crimean Tatar (Crimean Turkish) keyboard layouts
https://bugs.launchpad.net/bugs
Yes, AFAIK, crh.po is also a required file for the patch to be complete,
otherwise crh would need to be taken out of configure.in, and why would we want
to do that if it can be released instead.
The .po files apparently are compiled by the full build of xkeyboard-config,
which contains all .po
The 5 new strings contain the word "Crimean", and can be merged manually
if needed.
** Attachment added: ".pot patch reflecting 5 new strings in the main patch."
http://launchpadlibrarian.net/21793456/xkeyboard-config-crh-layouts-and-i18n-pot-only.patch
--
Patches for Crimean Tatar (Crimean
The last 2 patches, especially the last one, are optional.
** Attachment added: "ChangeLog patch, based on upstream, if needed."
http://launchpadlibrarian.net/21793510/xkeyboard-config-crh-layouts-and-i18n-ChangeLog-only.patch
--
Patches for Crimean Tatar (Crimean Turkish) keyboard layouts
h
** Attachment added: "If the package is going to be built from source,
including .pot, this patch is sufficient, although it excludes ChangeLog."
http://launchpadlibrarian.net/21793364/xkeyboard-config-crh-layouts-and-i18n-excluding-pot-and-ChangeLog.patch
** Bug watch added: freedesktop.org
Public bug reported:
Binary package hint: xkeyboard-config
Just committed up-stream, but alas it will not make it into jaunty.
Please commit these patches for the next Ubuntu release.
** Affects: xkeyboard-config
Importance: Unknown
Status: In Progress
** Affects: xkeyboard-config
82 matches
Mail list logo
