Re: New string additions
Le 15.06.19 à 00:26, Claude Paroz a écrit : > Le 14.06.19 à 11:58, Richard Hughes via gnome-i18n a écrit : >> On Fri, 14 Jun 2019 at 10:56, Daniel Mustieles García >> wrote: >>> Yes, this is due to a recent change in Damned Lies but seeing the problems >>> it might carry maybe we should discuss if it's worth to have it. >> >> Do you know where the appdata.loc file comes from in DL? I think now >> it's upstream gettext and it needs to be filed as an issue there. > > It came from https://github.com/hughsie/appstream-glib/tree/master/data > > I just reverted the change. And now I see the change was also added to the appstream metainfo.its (which I refreshed along with the patch). https://github.com/ximion/appstream/commit/78fc771c63 I'll continue the discussion on the ticket, on the base that gnome-i18n doesn't want all those release note strings. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New string additions
Le 14.06.19 à 11:58, Richard Hughes via gnome-i18n a écrit : > On Fri, 14 Jun 2019 at 10:56, Daniel Mustieles García > wrote: >> Yes, this is due to a recent change in Damned Lies but seeing the problems >> it might carry maybe we should discuss if it's worth to have it. > > Do you know where the appdata.loc file comes from in DL? I think now > it's upstream gettext and it needs to be filed as an issue there. It came from https://github.com/hughsie/appstream-glib/tree/master/data I just reverted the change. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL]String additions to 'gnome-builder.gnome-builder-3-32'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'gnome-builder.gnome-builder-3-32': + "A leak was fixed for semantic highlight indexes" + "A newly designed greeter." + "A newly designed omnibar with support for long running tasks with progress." + "A number of new command-line options have been added such as --clone, --greeter, --editor, --create-project, --preferences, and more." + "A number of new command-line options have been added." + "A number of plugins were redesigned to improve stability." + "Add setting to disable clearing build caches at startup." + "Additional snippets." + "Appdata updates" + "Auto-save will only activate if the file on disk has not been modified" + "Builder 3.32 is here with many features and improvements from the ground up!" + "Builder 3.32.1 is here with many bug fixes!" + "Builder 3.32.2 is here with many bug fixes!" + "Builder 3.32.3 is here with another round of bug fixes!" + "Builder will attempt to avoid re-installs when running if no files have changed." + "Editor search state is now preserved when saving session state." + "Enable VTE hyperlinks feature." + "Fix block selection in terminals." + "Fixes for struct/enum when auto-formatting C headers" + "Folder selection is fixed when cloning a repository." + "FreeDesktop notifications are now removed when the build pipeline has been invalidated" + "Glade design view improvements." + "Glade priorities were lowered to ensure that the editor has preference when opening .ui files" + "Hardening of GDBusServer usage" + "Improve CFLAGS and CXXFLAGS discovery with compile_commands.json when a direct match is not found (such as with headers)." + "Improve symlink detection warning." + "Improved meson project templates." + "Improved support for symlinks above the project directory" + "Improvements for Language Server Protocol." + "Keybindings improvements." + "LD_LIBRARY_PATH is now set under various conditions when running applications from non-default prefixes" + "Many new and simplified plugin interfaces." + "Meson unit tests are reloaded when build.ninja changes" + "Move app-menu to application windows." + "Multi-monitor support." + "NPM build system bug fixes and improvements." + "New desktop actions for the gnome-shell application context menu have been added." + "New styling based on updates to Adwaita." + "Project template improvements." + "RLS support can now be disabled by disabling the plugin" + "Scroll improvements for the source code editor" + "Some missing shortcuts were added to they shortcuts dialog" + "Source code line number background drawing is improved" + "Stability improvements to the flatpak plugin" + "Support for external plugins by requiring specific ABI checks." + "Support for non-project mode when opening files from the command-line or file-browser." + "Support for podman's --preserve-fds option" + "Support for updating git submodules along with other dependencies." + "The NPM plugin can now be disabled" + "The application-id is now validated from the template assistant" + "The buffer monitor has had a number of fixes for situations involving external file modifications" + "The clang plugin now discovers the location of the C++ standard includes." + "The code-index can be disabled by placing a \".noindex\" file in a directory" + "The diagnostic manager now properly tracks changes to a buffers configured source language. This will improve diagnostic detection in some situations." + "The file monitor now properly detects file changes when no version control is in use." + "The flatpak plugin now asks the user before installing dependencies" + "The foundry is now unloaded when shutting down a project, this fixed situations where build configurations were not saved" + "The makefile plugin now handles Makefile/makefile/GNUmakefile" + "The meson plugin handles changes to introspection format more gracefully" + "The project tree now includes version control information, build targets, and unit tests." + "The project-tree now auto-resizes the column" + "The unit tests panel now allows for cancelling an ongoing unit test." + "The unit tests panel now properly scrolls when a large amount of content is provided to the PTY." + "Transfer notifications have their cancel buttons restored" + "Unit Tests now integrate a terminal panel for tracking success." + "Unit tests will now properly run when uninstalled." + "Updated documentation" + "Updated documentation." + "Updated translations" + "Updated translations." + "Waf build system improvements" + "\"Open in Terminal\" will now properly open a terminal from the host system
Question on translating different script of language (ms-Arab)
I came here from GIMP translation page, I want to translate to Malay in Arabic script (also known as 'Jawi script') but from the look of current Malay language translation team they only do Malay in Latin script. Should I contact the Malay translation team for addition of this new script variation, or should I create new team for it myself? Due to the nature of Malay in Arabic script, the wording used will be slightly different from Malay in Latin script, and it is not expected to have the same translation in both scripts. Malay in Arabic script will have more native words for technical terms whereas Latin script will have more loanwords for technical terms. However, Malay in Arabic script is still an encompassing language and the same spelling and grammar are used across regions (mainly Malaysia, Brunei, South Thailand and some part of Indonesia such as in Riau) just like Malay in Latin script. This means the translation in Malay (Arabic) is not specific to Malaysia alone. Malay in Arabic script uses Arabic characters, with addition of a few letters namely: ca ( چ) for /t͡ʃ/ sound, nga (ڠ) for /ŋ/ sound, pa (ڤ) for /p/ sound, ga (ݢ) for /ɡ/ sound, ۏ (va) for /v/ sound and ye (ى) (ya without the dots) for /ə/ sound (or /a/ in selected Arabic loanwords into Malay but we're going to use native Malay words so that doesn't apply at all as /a/ in Malay native words is always an alif (ا) and never a ye (ى)). More info could be found in https://en.wikipedia.org/wiki/Jawi_alphabet (and on the citations of that wiki). Note that I don't have any basics in Arabic language itself, I only know Malay in Arabic script which is very easy whereas Arabic language is a completely different and hard to learn language. (Plus, every Malay learnt Malay in Arabic script in their 6 years of primary school and 5 years of secondary school, in Malaysia, whereas Arabic language is opt-in and most Malay avoided Arabic language). Language name in English: Malay (Arabic) Native language name: بهاس ملايو (جاوي) Translation of native language name: Malay language (Jawi) Romanized form of native language name: Bahasa Melayu (Jawi) Direct transliteration of native language name: bhas mlayw (jawi) Transliteration of native language name by abjad: ba-ha-alif-sin mim-lam-alif-ya-wau (jim-alif-wau-ya) ISO 15924 & IANA & BCP47 & language code under MacOS: ms-Arab On the other hand, r12a listed it as: zlm-arab I'm looking forward to the reply. --- Written by, muhdnurhidayat (Muhammad Nur Hidayat) A proud Malay Muslim feminine-leaning non-binary (enby) who want to maintain Malay heritage and culture while accepting new culture, an LGBTQ supporter who want everyone to live together in peace. I believe God makes no mistake, LGBTQ are born this way and shouldn't be punished or hated, it's God's plan all along to create diversity for human to know and respect each other (Quran [49:13]). ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
How to view release changes strings in action
I see strings for appdata.xml being added to the different GNOME software like gedit: msgid "This is a bugfix release for GNOME 3.32. Changes:" msgid "Reintroduce enable-gvfs-metadata build option" msgid "Fix several crash bugs" Etc. I would like to be able to see these strings in action so how/where can i see them? ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL]String additions to 'gnome-boxes.gnome-3-32'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'gnome-boxes.gnome-3-32': + "A new application icon" + "Attach USB tablet devices only for operating systems that are known to support it" + "Boxes 3.32.1 is the latest stable version of GNOME Boxes, and it contains all the features introduced since our 3.30 release. Some notable improvements include:" + "Change the default machine type to \"q35\", allowing for better support of PCI-E passthrough, using emulation of the ICH9 host chipset. The \"q35\" machine-type privides some advanced features, such as native PCI-E hotplug, Intel IOMMU, faster SATA emulation, and secure boot" + "Create new network interfaces for cloned machines. This way clones don't have conflicting MAC addresses" + "Default all input devices to use PS2 input bus" + "Enable 3D acceleration using the Virgl renderer for operating systems that are known to support it" + "Folder Sharing support for Flatpak" + "Free Red Hat Enterprise Linux 8.0 download" + "Introduce SSH support. Boxes can now be used as an SSH client." + "Perform passwordless express-installations only for operating systems known to support it" + "Populate the recommended downloads list from a static file. This allows distributors of Boxes to curate their own list" + "Propagate the system's default input source to the newly created VMs, so express-installs can have a consistent keyboard layout with their host" + "Remove the AppMenu, as a part of the GNOME initiative to move these options into the application window" + "Support express-installs for Ubuntu guests" + "Track and react to \"disconnect\" events from VNC and RDP remote machines" + "Use \"host-passphrough\" as default CPU mode, for maximum virtualization performance" + "Various search improvements in the \"Download an OS\" page" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/gnome-boxes/commits/gnome-3-32 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New string additions
No, I don't, but surely Claude knows it ;-) El vie., 14 jun. 2019 a las 11:58, Richard Hughes () escribió: > On Fri, 14 Jun 2019 at 10:56, Daniel Mustieles García > wrote: > > Yes, this is due to a recent change in Damned Lies but seeing the > problems it might carry maybe we should discuss if it's worth to have it. > > Do you know where the appdata.loc file comes from in DL? I think now > it's upstream gettext and it needs to be filed as an issue there. > > Richard. > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New string additions
On Fri, 14 Jun 2019 at 10:56, Daniel Mustieles García wrote: > Yes, this is due to a recent change in Damned Lies but seeing the problems it > might carry maybe we should discuss if it's worth to have it. Do you know where the appdata.loc file comes from in DL? I think now it's upstream gettext and it needs to be filed as an issue there. Richard. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New string additions
El vie., 14 jun. 2019 a las 10:25, Richard Hughes () escribió: > Hi Daniel, > > I don't think translating the release notes is a worthwhile thing to > do; Sure, but the problem here is that Damned Lies shows a lot of untranslated strings and translators have to download and review the files to discover if those new strings are from release notes or from UI. > the problem being is that translators don't get a chance to do it > for the current release between "write metainfo" and "prepare tarball" > as most maintainers just build the metainfo when they write > the NEWS file, i.e. at release time. > > I think the upstream appdata.its file marks these for translation > (shipped withlibappstream -- not maintained by me...), but that's not > something I agree with. > Yes, this is due to a recent change in Damned Lies but seeing the problems it might carry maybe we should discuss if it's worth to have it. Thanks for your comments! > Richard > > On Thu, 13 Jun 2019 at 14:40, Daniel Mustieles García > wrote: > > > > Yes, the Appdata file has release notes from very old versions... maybe > those strings could be removed/moved to another place. > > > > @Richard: any idea about how to deal with this? > > > > Thanks! > > > > El jue., 13 jun. 2019 a las 14:06, scootergrisen via gnome-i18n (< > gnome-i18n@gnome.org>) escribió: > >> > >> Den 13-06-2019 kl. 11:39 skrev Daniel Mustieles García via gnome-i18n: > >> > Hi Claude, > >> > > >> > Is due to this change that gnome-software[1] has about 600 > unstranslated > >> > new strings? > >> > > >> > It's a very big change in just one day... there is no way to reduce > it? > >> > > >> > Thanks in advance > >> > > >> > [1] https://l10n.gnome.org/vertimus/gnome-software/master/po/es/ > >> > > >> > >> Seems like strings for a lot of releases going back years: > >> > https://gitlab.gnome.org/GNOME/gnome-software/blob/master/data/appdata/org.gnome.Software.appdata.xml.in > >> > >> Not sure if there is much point translating all those strings and users > >> might not see them anyway. > >> > >> If i search for GNOME software in GNOME software it says version > >> 3.30.6-2ubuntu4.19.04.1 but i see none of those strings. Maybe because > >> the version number does not match any of the strings exactly. > >> > >> Seems like a wast of time translation strings for a 2014 release. > >> > >> When can a user ever see it? > >> > >> I normally prefer to have things fully translated but on SMPlayer > >> website i can also translate a few new strings on each release but i > >> find it a bit waste of time because in next release its already > outdated. > >> > >> If we have to translated release changes strings like this for every > >> software that would not be so much fun and the time could properly be > >> spendt better on improving the software. > >> ___ > >> gnome-i18n mailing list > >> gnome-i18n@gnome.org > >> https://mail.gnome.org/mailman/listinfo/gnome-i18n > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New string additions
Hi Daniel, I don't think translating the release notes is a worthwhile thing to do; the problem being is that translators don't get a chance to do it for the current release between "write metainfo" and "prepare tarball" as most maintainers just build the metainfo when they write the NEWS file, i.e. at release time. I think the upstream appdata.its file marks these for translation (shipped withlibappstream -- not maintained by me...), but that's not something I agree with. Richard On Thu, 13 Jun 2019 at 14:40, Daniel Mustieles García wrote: > > Yes, the Appdata file has release notes from very old versions... maybe those > strings could be removed/moved to another place. > > @Richard: any idea about how to deal with this? > > Thanks! > > El jue., 13 jun. 2019 a las 14:06, scootergrisen via gnome-i18n > () escribió: >> >> Den 13-06-2019 kl. 11:39 skrev Daniel Mustieles García via gnome-i18n: >> > Hi Claude, >> > >> > Is due to this change that gnome-software[1] has about 600 unstranslated >> > new strings? >> > >> > It's a very big change in just one day... there is no way to reduce it? >> > >> > Thanks in advance >> > >> > [1] https://l10n.gnome.org/vertimus/gnome-software/master/po/es/ >> > >> >> Seems like strings for a lot of releases going back years: >> https://gitlab.gnome.org/GNOME/gnome-software/blob/master/data/appdata/org.gnome.Software.appdata.xml.in >> >> Not sure if there is much point translating all those strings and users >> might not see them anyway. >> >> If i search for GNOME software in GNOME software it says version >> 3.30.6-2ubuntu4.19.04.1 but i see none of those strings. Maybe because >> the version number does not match any of the strings exactly. >> >> Seems like a wast of time translation strings for a 2014 release. >> >> When can a user ever see it? >> >> I normally prefer to have things fully translated but on SMPlayer >> website i can also translate a few new strings on each release but i >> find it a bit waste of time because in next release its already outdated. >> >> If we have to translated release changes strings like this for every >> software that would not be so much fun and the time could properly be >> spendt better on improving the software. >> ___ >> gnome-i18n mailing list >> gnome-i18n@gnome.org >> https://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
