Translation status

106 Strings 100%
Browse Translate
2,373 Words 100%
17,242 Characters 100%

Strings status

Strings Words Characters
106 2,373 17,242
All strings Browse Translate Zen
106 2,373 17,242
Translated strings Browse Translate Zen

Overview

Project website www.linuxfromscratch.org
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository git@git.linuxfromscratch.org:fr-lfs
Repository branch trunk
Last remote commit Automatic BLFS commit based on daabb2ab98ba18982452da5fd8b6e27e7fac1cff 416c8c8069
Julien Lepiller authored 2 hours ago
Last commit in Weblate Automatic BLFS commit based on daabb2ab98ba18982452da5fd8b6e27e7fac1cff 416c8c8069
Julien Lepiller authored 2 hours ago
Weblate repository https://translate.linuxfromscratch.org/git/faq/faq/
File mask lfs/*/chapter10/kernel.po
Translation file Download lfs/pt_BR/chapter10/kernel.po
Last change Dec. 13, 2024, 10:13 p.m.
Last author None
a week ago

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 106 2,373 17,242
Translated 100% 106 100% 2,373 100% 17,242
Needs editing 0% 0 0% 0 0% 0
Read-only 0% 0 0% 0 0% 0
Failing checks 0% 0 0% 0 0% 0
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

0 changes 104 changes 0 changes 8 changes 0 changes 7 changes 0 changes 0 changes 126 changes 0 changes 0 changes 0 changes 10 changes 7 changes 44 changes 0 changes 1 change 0 changes 6 changes 3 changes 0 changes 6 changes 0 changes 0 changes
Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov

Quick numbers

2,373
Hosted words
106
Hosted strings
100%
Translated
2
Contributors
and previous 30 days

Trends of last 30 days

+18%
Hosted words
+100%
+6%
Hosted strings
+100%
—
Translated
+100%
+100%
Contributors
—
User avatar None

Changes committed
Changes committed a week ago
User avatar jamenson

Translation completed
Translation completed a week ago
User avatar jamenson

Translation added
On the other hand, if you've upgraded GCC, you should run <command>make clean</command> to purge all the <filename class='extension'>.o</filename> files from the previous build, or the new build may fail.
Por outro lado, se você tiver atualizado o GCC, você deveria executar <command>make clean</command> para expurgar todos os arquivos <filename class='extension'>.o</filename> provenientes da construção anterior, ou a nova construção possivelmente falhe.
a week ago
User avatar jamenson

Translation added
If you are updating the configuration and rebuilding the kernel from a retained kernel source tree, normally you should <emphasis role='bold'>not</emphasis> run the <command>make mrproper</command> command. The command would purge the <filename>.config</filename> file and all the <filename class='extension'>.o</filename> files from the previous build. Despite it's easy to restore <filename>.config</filename> from the copy in <filename class='directory'>/boot</filename>, purging all the <filename class='extension'>.o</filename> files is still a waste: for a simple configuration change, often only a few <filename class='extension'>.o</filename> files need to be (re)built and the kernel build system will correctly skip other <filename class='extension'>.o</filename> files if they are not purged.
Se você estiver atualizando a configuração e reconstruindo o núcleo a partir de uma árvore retida de fonte do núcleo, normalmente você <emphasis role='bold'>não</emphasis> deveria executar o comando <command>make mrproper</command>. O comando expurgaria o arquivo <filename>.config</filename> e todos os arquivos <filename class='extension'>.o</filename> provenientes da construção anterior. Apesar de ser fácil restaurar <filename>.config</filename> a partir da cópia em <filename class='directory'>/boot</filename>, expurgar todos os arquivos <filename class='extension'>.o</filename> ainda é um desperdício: para uma simples mudança de configuração, geralmente somente uns poucos arquivos <filename class='extension'>.o</filename> precisam ser (re)construídos e o sistema de construção do núcleo ignorará corretamente outros arquivos <filename class='extension'>.o</filename> se eles não forem expurgados.
a week ago
User avatar None

Resource updated
The “lfs/pt_BR/chapter10/kernel.po” file was changed. 8 days ago
User avatar None

String added in the repository
On the other hand, if you've upgraded GCC, you should run <command>make clean</command> to purge all the <filename class='extension'>.o</filename> files from the previous build, or the new build may fail.
 
8 days ago
User avatar None

String added in the repository
If you are updating the configuration and rebuilding the kernel from a retained kernel source tree, normally you should <emphasis role='bold'>not</emphasis> run the <command>make mrproper</command> command. The command would purge the <filename>.config</filename> file and all the <filename class='extension'>.o</filename> files from the previous build. Despite it's easy to restore <filename>.config</filename> from the copy in <filename class='directory'>/boot</filename>, purging all the <filename class='extension'>.o</filename> files is still a waste: for a simple configuration change, often only a few <filename class='extension'>.o</filename> files need to be (re)built and the kernel build system will correctly skip other <filename class='extension'>.o</filename> files if they are not purged.
 
8 days ago
User avatar None

String updated in the repository
This will make the kernel correctly display the message in case a kernel panic happens and a running DRM driver supports to do so. Without this, it would be more difficult to diagnose a panic: if no DRM driver is running, we'd be on the VGA console which can only hold 24 lines and the relevant kernel message is often flushed away; if a DRM driver is running, the display is often completely messed up on panic. As of Linux-6.12, none of the dedicated drivers for mainstream GPU models really supports this, but it's supported by the <quote>Simple framebuffer driver</quote> which runs on the VESA (or EFI) framebuffer before the dedicated GPU driver is loaded. If the dedicated GPU driver is built as a module (instead of a part of the kernel image) and no initramfs is used, this functionality will work just fine before the root file system is mounted and it's already enough for providing information about most LFS configuration errors causing a panic (for example, an incorrect <parameter>root=</parameter> setting in <xref linkend='ch-bootable-grub'/>).
Isso fará com que o núcleo exiba corretamente a mensagem caso ocorra um pânico de núcleo e um controlador DRM em execução suporte fazer isso. Sem isso, seria mais difícil diagnosticar um pânico: se nenhum controlador DRM estiver em execução, nós estaríamos no console VGA que só pode conter 24 linhas e a mensagem relevante do núcleo frequentemente é descartada; se um controlador DRM estiver em execução, a exibição geralmente fica completamente bagunçada no pânico. A partir do Linux-6.12, nenhum dos controladores dedicados para modelos de GPU convencionais realmente suporta isso, mas é suportado pelo <quote>Simple framebuffer driver</quote> que executa no framebuffer VESA (ou EFI) antes do controlador de GPU dedicado ser carregado. Se o controlador de GPU dedicado for construído como um módulo (em vez de parte da imagem do núcleo) e nenhum initramfs for usado, essa funcionalidade funcionará perfeitamente antes que o sistema de arquivos raiz seja montado e já será suficiente para fornecer informações acerca da maioria dos erros de configuração do LFS que causam um pânico (por exemplo, uma configuração <parameter>root=</parameter> incorreta em <xref linkend='ch-bootable-grub'/>).
8 days ago
User avatar None

Changes committed
Changes committed 2 weeks ago
User avatar jamenson

Translation completed
Translation completed 2 weeks ago
Browse all translation changes