Skip to content

Translation refactoring - #179

Closed
SebastianoPistore wants to merge 3 commits into
amule-project:masterfrom
SebastianoPistore:translation_ref
Closed

Translation refactoring#179
SebastianoPistore wants to merge 3 commits into
amule-project:masterfrom
SebastianoPistore:translation_ref

Conversation

@SebastianoPistore

@SebastianoPistore SebastianoPistore commented Feb 20, 2020

Copy link
Copy Markdown
Contributor
  • header standardized for all files based on this model
# Translation of amule interface to English
# aMule i18n resource file.
# Copyright (c) 2003-2020 aMule Team
# This file is distributed under the same license as the aMule package.
#
# TranslatorName <[email protected]>, 2020.

It is now easier to understand the content of the file, the language of the translation, the copyright holder, the license and the names of all the people who work / worked on a translation.

  • PO aligned with the latest version of POT (not translated but ready to resume translation)

  • updated translations IT and IT_CH

- header standardized for all files based on this model

# Translation of amule interface to English
# aMule i18n resource file.
# Copyright (c) 2003-2020 aMule Team
# This file is distributed under the same license as the aMule package.
#
# TranslatorName <[email protected]>, 2020.
#

It is now easier to understand the content of the file, the language of the translation, the copyright holder, the license and the names of all the people who work / worked on a translation.

- PO aligned with the latest version of POT (not translated but ready to resume translation)

- updated translations IT and IT_CH
@Vollstrecker

Copy link
Copy Markdown
Collaborator

Sorry, but that won't work. As we use po4a dir translation generation, your changes will BE overwritten on the next run.

As I'm not at home, I can't tell you from my mind how to do this, but the docs are out there.

@SebastianoPistore

Copy link
Copy Markdown
Contributor Author

Sorry, but that won't work. As we use po4a dir translation generation, your changes will BE overwritten on the next run.

Ok: thanks for telling me, so copying the updated po is not enough. I took a quick look at po4a and it looks very versatile, I didn't know it.
But I did not understand the workflow exactly: generate the pot from the program code, update the po from the pot and then? How do you put them on
translations in the program? They generate the mo file, right? And to prevent the subsequent update from overwriting what I did, how do you do it?
Thanks

@SebastianoPistore SebastianoPistore changed the title Translation refactoring (wip): Translation refactoring Mar 2, 2020
@Vollstrecker

Copy link
Copy Markdown
Collaborator

Ups, sorry my bad. po4a is used for the manpages. po-files already are translated as po-files.
Short question: were did you get the additional lines that are deleted? de.po has many deletions beginning from 7643, while our file ends at 7644.

@SebastianoPistore

Copy link
Copy Markdown
Contributor Author

Short question: were did you get the additional lines that are deleted? de.po has many deletions > beginning from 7643, while our file ends at 7644.

I deleted lines due to the updating of the file: I updated de.po with the pot, then deleted the string (which for the most part are changed sentences).
For example:
"Copyright (C) 2003-2008 aMule Team \n"
was no longer used, while
"Copyright (c) 2003-2019 aMule Team \n"
has been added to amule.
So both were present in the file I deleted the first one, so the code is cleaner.

@SebastianoPistore SebastianoPistore changed the title (wip): Translation refactoring Translation refactoring Mar 5, 2020
Commit 730eb00 (Translation refactoring)
accidentally changed encoding from UTF-8 to ISO-8859-1.
@gonosztopi

Copy link
Copy Markdown
Member

I squashed and committed this pull request as 2027b0c, only GitHub doesn't recognize it as being merged, therefore closing now.

@gonosztopi gonosztopi closed this Jul 15, 2020
@SebastianoPistore
SebastianoPistore deleted the translation_ref branch July 15, 2020 15:23
mrjimenez pushed a commit to mrjimenez/amule that referenced this pull request Jun 17, 2026
…-colors

ui: theme-aware list-control colours (drop hardcoded *wxBLACK/BLUE/RED)
got3nks added a commit to got3nks/amule that referenced this pull request Jul 2, 2026
…mule-project#274)

PR amule-project#179 keyed the theme-aware palette off
wxSystemSettings::GetAppearance().IsDark(). On macOS + wxGTK that
matches what the native wxListCtrl actually paints — dark mode
propagates to the list background — so the light-tone palette is
readable. On native Win32 (SysListView32) the story is different:
even with AppsUseLightTheme=0, the list keeps its default white
background, and light-tone text lands on it unreadable. Users see
near-white search-result text on white background in the search tab
(amule-project#274, Windows 11 dark mode).

Fix: pick the palette from the list control's own background colour
at draw time, not the OS appearance flag. On Linux/macOS the
background follows the system theme so behaviour is unchanged; on
Windows the list stays white so the (readable) light-mode palette
is used regardless of the AppsUseLightTheme registry setting. When
wxWidgets eventually gets full Win32 dark-mode wxListCtrl support
(DWMWA_USE_IMMERSIVE_DARK_MODE etc.) the helper self-corrects:
background turns dark, luminance test flips, dark-mode palette
kicks in.

Helper lives in MuleListCtrl.h next to the shared list-ctrl base;
sites in SearchListCtrl.cpp + GenericClientListCtrl.cpp are the
three call sites amule-project#179 introduced.
ngosang pushed a commit to ngosang/amule that referenced this pull request Jul 2, 2026
…mule-project#274) (amule-project#276)

* fix(ui): key list-ctrl palette off actual background, not IsDark() (amule-project#274)

PR amule-project#179 keyed the theme-aware palette off
wxSystemSettings::GetAppearance().IsDark(). On macOS + wxGTK that
matches what the native wxListCtrl actually paints — dark mode
propagates to the list background — so the light-tone palette is
readable. On native Win32 (SysListView32) the story is different:
even with AppsUseLightTheme=0, the list keeps its default white
background, and light-tone text lands on it unreadable. Users see
near-white search-result text on white background in the search tab
(amule-project#274, Windows 11 dark mode).

Fix: pick the palette from the list control's own background colour
at draw time, not the OS appearance flag. On Linux/macOS the
background follows the system theme so behaviour is unchanged; on
Windows the list stays white so the (readable) light-mode palette
is used regardless of the AppsUseLightTheme registry setting. When
wxWidgets eventually gets full Win32 dark-mode wxListCtrl support
(DWMWA_USE_IMMERSIVE_DARK_MODE etc.) the helper self-corrects:
background turns dark, luminance test flips, dark-mode palette
kicks in.

Helper lives in MuleListCtrl.h next to the shared list-ctrl base;
sites in SearchListCtrl.cpp + GenericClientListCtrl.cpp are the
three call sites amule-project#179 introduced.

* clang-format: adjust pointer style in IsListBackgroundDark decl
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants